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ABSTRACT 


Thirteen  computer  programs  are  examined  for  potential  appli- 
cation to  the  Modular  Integrated  Utility  System  (MIUS)  program.  The 
software  programs  considered  calculate  all  or  partial  combinations  of: 
heating  and  cooling  loads,  simulation  of  physical  systems  to  determine 
the  energy  requirements  necessary  to  satisfy  those  loads,  prediction  of 
optimal  operation  schedules  and  associated  costs,  and  accomplishment  of 
full  life-cycle  economic  analyses.  A set  of  criteria  for  evaluation  of 
this  software  is  presented.  Information  regarding  the  programs,  obtained 
from  user  manuals  and  a series  of  seminar  presentations,  is  collected  and 
systematically  summarized  in  a standardized  format  using  information 
available  as  of  June  1974.  An  evaluative  summary  of  each  program  as  of 
that  date  is  given.  Program  comparison  activities  are  discussed  and 
evaluated.  Conclusions  regarding  applicability,  validity,  and  utility  of 
the  programs  are  reached.  Recommendations  are  made  concerning  future 
software  development  and  utilization. 


Keywords:  Computer  programs;  cooling;  energy  analysis;  financial  anal- 

ysis; heating;  load  calculation;  MIUS;  modular  integrated 
utility  system;  simulation;  utility  services 
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FOREWORD 


The  Department  of  Housing  and  Urban  Development  (HUD)  is 
conducting  the  Modular  Integrated  Utility  System  (MIUS)  Program  de- 
voted to  development  and  demonstration  of  the  technical,  economic, 
and  institutional  advantages  of  integrating  the  systems  for  providing 
all  or  several  of  the  utility  services  for  a community.  The  utility 
services  include  electric  power,  heating  and  cooling,  potable  water, 
liquid  waste  treatment,  and  solid  waste  management.  The  objective  of 
the  MIUS  concept  is  to  provide  the  desired  utility  services  consistent 
with  reduced  use  of  critical  natural  resources,  protection  of  the 
environment,  and  minimized  cost.  The  program  goal  is  to  foster,  by 
effective  development  and  demonstration,  early  implementation  of  the 
integrated  utility  system  concept  by  the  organization,  private  or 
public,  selected  by  a given  community  to  provide  its  utilities. 

Under  HUD  direction  several  agencies  have  participated  in  the 
HUD-MIUS  Program,  including  the  Energy  Research  and  Development  Adminis- 
tration (ERDA) ; the  Departments  of  Defense  (DOD) ; Health,  Education  and 
Welfare  (HEW) ; and  Interior  (DOI) ; the  Environmental  Protection  Agency 
(EPA);  the  National  Aeronautics  and  Space  Administration  (NASA);  and  the 
National  Bureau  of  Standards  (NBS) . 

This  publication  is  one  of  a series  developed  under  the  HUD- 
MIUS  Program  and  is  intended  to  further  a particular  aspect  of  the 
program  goals. 
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Drafts  of  technical  documents  are  reviewed  by  the  agencies 
participating  in  the  HUD-MIUS  Program.  Comments  are  assembled  into  a 
Coordinated  Technical  Review.  The  draft  of  this  publication  received 
such  a review  and  all  comments  were  resolved. 
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1.  Introduction 


In  the  conceptual  development  and  technology  evaluation  phase 
of  the  multi-agency  HUD-MIUS  Program,  the  use  of  computerized  calcula- 
tion procedures  by  several  of  the  participating  agencies  started  early 
and  played  an  important  role  in  analyses  ranging  from  site  load  deter- 
mination, to  determination  of  overall  soundness  of  different  concepts 
and  technologies,  to  detailed  evaluation  of  total  MIUS  designs.  The 
NASA  and  ORNL  developed  computer  programs  to  estimate  building  thermal 
loads  and  the  subsequent  required  energy  input  to  various  plant  configura- 
tions which  satisfy  those  thermal  loads.  At  the  request  of  HUD,  the  NBS 
team  of  the  HUD-MIUS  Program  examined  the  various  calculational  procedures 
in  use  for  soundness  of  approach,  and  for  compatibility  of  efforts  of 
the  different  agencies.  In  addition,  some  commercially  available  software 
was  examined  in  order  to  determine  if  there  were  any  programs  which 
could  be  of  use.  This  report  describes  the  information  derived  from 
the  effort,  and  results  in  a series  of  recommendations  to  the  HUD 
Program  Manager  both  as  to  those  programs  best  able  to  satisfy  present 
MIUS  needs  and  to  what  additional  computer  program  development  is  needed 
for  future  work. 

All  programs  were  evaluated  with  respect  to  their  potential 
contribution  to  the  generation  and  evaluation  of  MIUS  designs  in  the 
demonstration  and  follow-on  phases  of  the  MIUS  effort.  The  program 
descriptions  and  evaluations  are  based  in  part  on  training  courses 
presented  by  program  developers  and  in  part  on  published  descriptive 
material  concerning  the  programs. 


The  reader  is  cautioned  that  computer  programs  are  constantly 
evolving.  The  descriptions  and  evaluations  which  follow  are  based  on 
the  information  available  as  of  June  1974.  Changes  which  have  been  made 
to  several  of  the  programs  since  that  date  are  not  addressed. 

This  evaluation  gives  consideration  to  some  past  comparison 
activities  and  summarizes  their  findings.  It  is  noted  that  there  are 
no  publicly  available  evaluations  of  program  accuracy,  only  evaluations 
of  relative  agreement  between  programs.  Three  of  the  comparisons  were 
carried  out  by  government  agencies  participating  in  the  MIUS  effort. 

Several  conclusions  are  reached  concerning  MIUS  needs  for 
computer  support.  Recommendations  are  made  for  implementation  of 
specific  computer  programs  which  come  closest  to  satisfying  the  identi- 
fied MIUS  needs.  Due  to  the  simulation  flexibility  required  for  MIUS 
studies,  only  programs  for  which  the  plant  systems  simulation  package 
was  available  to  participating  agencies  in  source  language  form  could 
be  recommended. 

This  report  of  the  evaluation  effort  is  presented  with  the 
intention  that  the  program  description  data,  evaluative  summaries, 
comparison  activities  and  conclusions  will  assist  in  subsequent  MIUS 
efforts  for  the  design  and  energy  analysis  of  community  energy  systems. 
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2.  Evaluation  Criteria 


A particular  perspective  was  established  from  which  all  of  the 
computer  programs  described  herein  were  examined  in  forming  an  evaluation. 
Applicability  and  usefulness  in  furthering  MIUS  project  goals  were  a 
primary  concern.  In  addition,  the  validity  or  quality  of  the  consitutent 
algorithms  was  examined  to  the  degree  possible  without  actual  line- 
by-line  algorithmic  analysis.  This  examination  was  based  on  avail- 
able program  documentation,  training  seminars,  and  oral  and  written 
communication  with  the  authors  of  the  computer  programs.  Although  pre- 
viously initiated  comparison  test  case  activities  are  discussed  and 
evaluated  in  Section  4 of  this  report,  no  specific  test-case  comparisons 
were  involved  in  the  present  effort. 

To  best  accomplish  this  effort,  a set  of  evaluation  criteria  were 
developed  by  which  the  characteristics  and  capabilities  of  each  program 
were  systematically  examined.  These  criteria  are  divided  into  four 
general  categories:  a)  applicability  to  the  MIUS  effort;  b)  simulation 

adequacy;  c)  user  factors  of  the  programs;  d)  implicit  simulation  bias. 

The  first  area  of  concern  is  that  of  program  applicability,  i.e. 
does  a given  program  or  software  system  calculate  something  that  is 
needed  in  a MIUS  analysis.  Determination  of  technical  and  economic 
feasibility  is  necessary  for  survival  of  the  MIUS  concept.  The  early 
efforts  of  the  MIUS  program  were  largely  directed  to  this  end.  Critical 
to  achieving  this  determination  is  the  ability  to  predict,  either  in  an 
absolute  or  in  a comparative  sense  (the  importance  of  the  distinction 

between  these  will  be  discussed  in  connection  with  the  next  general 
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area),  the  energy  utilization  or  economics  or  both  of  a MIUS  configuration 
which  satisfies  a given  set  of  utility  demands.  It  is  important  that 
comparative  information  on  energy  utilization  and  economics  is  sufficient 
to  enable  determination  of  an  optimum  configuration  (this  is  likely  to 
involve  several  iterations)  and  also  to  allow  comparison  with  conventional 
utility  systems  satisfying  the  same  demands.  The  determination  of  the 
various  utility  demands  as  a function  of  time  for  a given  site  application 
is  an  activity  peripheral  to  the  MIUS  program  scope.  However,  it  is 
necessary  that  MIUS  staff  be  capable  of  determining  utility  services 
demands,  even  though  work  in  this  area  does  not  directly  support  the 
HUD-MIUS  program  objective  to  evaluate  alternative  methods  of  satisfying 
these  demands.  A clear  distinction  must  be  made  between  the  study  of 
factors  in  the  end-use  structures  which  affect  the  utility  services 
demands,  and  the  factors  which  affect  MIUS  performance  in  satisfying 
those  demands.  A software  system  which  proposes  to  do  energy  analyses, 
but  primarily  concerns  itself  with  analysis  of  in-building  energy  transfer 
systems,  and  only  secondarily  with  the  types  of  energy  transfer  systems 
that  occur  in  a MIUS  plant  configuration,  is  of  limited  use  to  the  MIUS 
effort  for  either  conceptual  or  design  evaluation.  However,  MIUS  design 
optimization  is  enhanced  by  an  accurate  calculation  of  site  utility 
loads,  and  for  this  reason  computer  programs  which  accomplish  this  are 
considered  in  this  report. 

A second  general  area  of  evaluative  concern  is  the  nature  and 
adequacy  of  the  simulations,  or  mathematical  models,  that  lie  at  the 
core  of  the  different  analyses.  This  concern  is  related  to  quantifying 
the  concept  of  the  accuracy,  or  reliability  of  a calculated  result  and 
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is  particularly  important  in  the  case  of  the  energy  performance  aspects 
the  MIUS.  A mathematical  model  of  a complex  configuration  such  as  the 
MIUS  is  obtained  by  examining  its  constituent  parts,  developing  separate 
models  for  each  of  those  parts,  and  then  combining  the  individual  models 
in  an  appropriate  logical  configuration  that  matches  the  hardware  inter- 
connections of  the  real  system.  In  principle,  if  the  mathematical 
model  (assuming  no  errors  in  concept)  is  created  in  enough  detail,  it 
can  come  arbitrarily  close  to  simulating  the  behavior  of  the  real  system 
of  interest.  In  practice,  limitations  of  cost  and  effort  involved  in 
obtaining  a perfectly  accurate  simulation  model  are  great,  and  simplifying 
assumptions  are  introduced  that  also  have  the  effect  of  decreasing  the 
accuracy.  The  question  then  is  to  determine  the  amount  of  accuracy 
needed  in  a model  that  is  sufficient  to  satisfy  the  needs  of  the  user. 

In  the  case  of  MIUS  energy  performance  simulation,  there  is  in  fact  not 
a single  answer  to  this  question,  since  there  are  differing  needs.  To 
determine  comparative  performance  either  for  feasibility  or  optimization 
studies,  a simple  steady-state  or  equilibrium  model  will  siffice.  For 
the  case  where  an  estimate  of  absolute  performance  is  needed,  or  where  a 
question  of  control  stability  under  certain  conditions  of  demand  and 
response  must  to  be  answered,  a more  complicated  model  which  simulates 
transient  response  has  to  be  incorporated.  For  the  programs  discussed 
in  this  report,  the  adequacy  of  the  simulation  will  be  considered  in 
light  of  the  use  for  which  the  program  is  intended. 

The  third  general  area  of  evaluation  centers  around  the  various 
aspects  that  become  important  in  utilization  of  a program  and  may  be 

These  depend  strongly  on  who  the  user  is  - in 
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called  "user  factors." 


this  case,  primarily  the  professional  technical  staffs  of  the  agency 
participants  who  are  involved  in  performing  calculations  for  the  MIUS 
effort.  They  are  generally  knowledgeable  in  the  hardware  engineering 
aspects,  in  the  various  concepts  of  performance  simulation  and  program- 
ming techniques,  and  are  using  computer  programs  as  research  and  develop- 
ment tools.  To  this  type  of  user,  flexibility  and  adaptability  of  a 
program  to  a wide  range  of  problems  are  more  important  than  clear  input 
or  output  which  appeals  to  the  non-technical  user  who  occasionally 
purchases  the  services  of  a commercially  available  program.  Another 
aspect  of  importance  is  the  logical  structure  of  the  program.  One  that 
is  constructed  in  logical  modules  is  more  accessible  to  evaluation,  debug- 
ging, and  alteration;  and  to  the  addition  of  increased  capabilities  at 
some  future  date  as  the  need  arises.  In  the  case  of  programs  (commercial  or 
otherwise)  developed  elsewhere,  documentation  quality  is  of  great 
importance,  as  is  availability.  For  those  commercial  programs  that 
might  be  of  use,  cost  and  ownership  are  both  important  considerations, 
the  latter  being  by  far  the  most  important.  It  is  imperative  that 
agency  users  know  exactly  how  a program  arrives  at  a solution  in  order 
to  determine  to  their  own  satisfaction  that  a valid  procedure  is  being 
used.  Lt  is  this  single  factor  more  than  anything  else  that  leads  to  a 
general  recommendation  against  the  use  of  proprietary  software  even  for 
those  programs  that  have  good  reputations. 

The  fourth  area,  which  is  related  to  the  preceding  discussion,  is 
the  concern  that  commercial  programs  may  be  biased  in  such  a way  as  to 
systematically  favor  particular  configurations  over  others.  This  idea 
ot  built-in  bias  is  a very  difficult  one  to  assess.  Even  though  they 
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are  very  complex,  no  evidence  of  favoritism  of  one  type  of  system  over 
another  has  been  found  in  the  algorithms  that  have  been  examined.  On 
the  other  hand,  the  complexity  of  the  program  itself  can  be  used  as  a 
subtle  tool  for  bias  by  making  it  more  difficult  to  analyze  some  configu- 
rations than  others.  This  tends  to  discourage  a complete  examination  of 
the  widest  range  of  systems  that  could  be  considered  for  a given  appli- 
cation, and  instead  concentrates  the  analysis  of  those  types  of  systems 
that  the  owner/supplier  of  the  program  wants  his  client  to  see.  In 
terms  of  motive,  one  would  not  expect  this  to  be  a problem  with  all  of 
the  commercial  programs,  but  only  with  those  developed  and  marketed  by 
interests  that  use  the  program  as  a tool  to  "market"  certain  types  of 
systems.  In  those  latter  cases  if  the  program  can  be  examined  in  detail, 
this  type  of  bias  can  be  guarded  against.  Even  if  the  program  cannot 
be  examined  in  detail,  user  control  over  specification  of  the  system 
configuration  which  is  to  be  analyzed  still  affords  some  protection. 

In  summary,  the  four  areas  discussed  above  form  the  basic  criteria 
against  which  the  programs  selected  for  this  study  were  reviewed.  They 
can  be  stated  as  applicability,  simulation  adequacy  and  comprehensiveness, 
user  factors  and  implicit  bias.  As  will  be  described  in  more  detail  in 
the  next  section  of  this  report,  the  description  of  each  program  is 
broken  down  into  categories  and  is  concluded  by  an  evaluative  summary. 

The  evaluative  summary  for  each  program  consists  of  a discussion  of  the 
program  characteristics  evaluated  with  respect  to  the  criteria  discussed 
above.  The  systematic  description  format  provides  an  effective  way  of 
presenting  the  information  about  program  characteristics  in  order  to 

aid  in  the  evaluation  of  each  program. 
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3.  Program  Data  and  Evaluations 
In  order  to  aid  in  systematic  individual  analyses  relative 
to  the  previously  described  criteria  and  in  comparison  of  the  programs 
that  were  studied,  a set  of  21  characteristics  were  devised.  Descriptions 
of  each  of  the  programs  studied  were  made  in  terms  of  these  standard 
characteristics.  Individual  agencies  were  requested  to  accomplish  this 
task  for  programs  they  developed,  while  NBS  completed  the  summaries  for 
the  commercial  programs.  The  characteristics  tended  to  fall  naturally 
into  three  broad  categories.  The  first  deals  with  administrative  items 
such  as  source(s),  availability,  cost  and  other  characteristics  of 
immediate  interest  to  a potential  user  of  a software  system.  The 
second  category  contains  characteristics  related  to  the  computational 
aspects  of  the  system,  such  as  the  types  of  calculations  made,  inputs, 
outputs,  and  the  logical  structure  of  the  system.  The  third  category 
is  associated  with  detailed  technical  characteristics  of  the  software 
itself,  such  as  the  source  language,  the  hardware  on  which  it  is 
currently  implemented,  responsibility  for  maintenance  and  updating 
of  the  software  and  so  forth.  Detailed  descriptions  of  each  of  the  21 
characteristics  follow: 

Administrative  Category 

1.  Abstract : 

A short  summary  of  software  system  (program)  capabilities. 

2 . Author (s)  : 

Person(s)  who  developed  the  software,  if  known,  or  known 
contact (s)  who  are  technically  very  familiar  with  the 
software  contents. 


8 


3 .  Owner (s)  : 


Person  (organization)  who  has  ownership  rights  over  the  software 
system. 

4 . Availability; 

How  easy  (or  difficult)  is  it  to  obtain  the  system,  or  the  use 
of  the  computational  services  provided  by  this  system  (program) . 

5 . Cost : 

The  expense  of  obtaining  the  system  itself,  or  obtaining  the 
use  of  the  system,  in  arbitrary  units  (e.g.  $/"run",  $/minute) . 

It  is  recognized  that  the  pertinent  quantity  to  be  used  will  be 
different,  depending  on  whether  the  program  is  proprietary  or  not. 
It  should  be  noted  that  purchase  and  use  costs  are  quite  different 
and  serve  different  purposes.  Also,  use  costs  alone  can  vary 
widely  even  for  the  same  program  depending  on  individually 
negotiated  contracting  arrangements.  Additional  information 
on  program  costs  is  given  in  reference  [1].* 

6 . Human  Factors: 

Amount  and  difficulty  of  input  preparation  required.  Clarity 
of  the  output. 

7 . Turnaround : 

Time  required  to  get  results  from  the  time  input  sheets  are 
filled  out.  User  procedures  required  for  processing. 

8 . Documentation : 

Identification,  availability,  and  a short  content  summary 
of  documentation  available  for  the  software  system  (program) . 

Computational  Category 

9 . Scope ; 

From  a technical  point  of  view  the  most  important  category 
in  this  outline.  A summary  statement  of  what  the  system  can 
do  and  how  it  achieves  this. 

10 . Output : 

Quantities  presented  on  the  final  printout.  This  may  include 
echoes  of  input  data  as  well  as  calculated  results.  Availability 
of  options  on  output  completeness. 

*Numbers  in  brackets  indicate  references  listed  at  end  of  text. 
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11.  Input : 


Input  quantities  necessary  to  do  an  analysis.  How  few?  How  many? 
Availability  of  default  options  if  partial  input  is  desired. 

12 . Logical  Structure: 

The  logical  flow  of  the  system  elements. 

13.  Flexibility: 

The  range  of  applicability  of  the  system. 

14 . Interfacing: 

Identification  of  complementary,  independently  developed  systems 
for  which  software  linkages  to  this  system  exist. 

15.  Limitations : 

Explicit  and/or  implicit  limitations  in  the  ability  of  the  system 
to  produce  useful  results.  One  type  of  limitation  may  be,  typically, 
a limited  range  of  applicability,  another  type  would  be  questionable 
or  simplistic  model  of  a physical  process. 

Sof tware/Hardward  Technical 

I 6 . Source  Language: 

e.g.  ASA  Fortran,  PL/1,  and  so  forth. 

17.  Hardward  Implementation: 

Known  hardware  environments  on  which  the  software  system  (program) 
is  operational. 

18 . Portability : 

Difficulty  involved  in  transferring  this  system  (program)  from 
one  hardware  environment  to  another. 

19.  Diagnostics : 

Completeness  and  scope  of  system  (program)  in  monitoring  itself 
(i.e.  detecting  internally  developed  faults)  and  in  protecting 
against  improper  (inapplicable)  use. 

20 . Maintenance : 

Person  or  organization  responsible  for  maintaining  the  software. 
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21.  Adaptability/Expandability : 


Ease  (or  difficulty)  of  implementing  changes  or  additions  to  the 
software,  if  it  were  desired  to  modify  the  present  scope  of 
the  system. 

Data  on  the  surveyed  programs  follows  the  above  format.  The 
characteristics  are  not  universally  applicable  to  the  programs  considered. 
In  the  case  of  proprietary  programs,  information  pertinent  to  many 
characteristics  is  often  not  available. 

Based  on  the  presented  data  for  each  program,  the  actual  evaluative 
process  was  conducted  systematically  and  with  respect  to  the  criteria 
described  in  ihe  last  section.  An  evaluative  summary  follows  the  data  for 
each  program  as  the  twenty-second  item.  The  summaries  are  based  on  the 
program  characteristics  as  delineated  in  the  categories.  The  evaluation  is 
with  respect  to  the  criteria  described  in  the  previous  section  of  this 
report.  These  summaries  by  their  nature  highlight  the  most  significant 
findings  and  do  not  in  some  cases  describe  the  complete  evaluation  process. 
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3.1 


Heating-Cooling  Calculation  III  (HCC-IIl) 


1.  Abstract ; 

A computerized  procedure  for  calculating  design  heating 
and  cooling  loads  for  buildings  in  accordance  with  American 
Society  of  Heating,  Refrigeration  and  Air  Conditioning  Engineers 

(ASHRAE) methodology . 

2.  Author  (s) : 

Unknown 

3.  Owner (s)  : 

Automatic  Procedures  for  Engineering  Consultants,  Inc.  (APEC) 

Suite  M-15 

Grant-Deneau  Tower 

4th  and  Ludlow  Streets 

Dayton,  Ohio  45402 

4 . Availability : 

Available  to  members  of  APEC  as  a user  service. 


5.  Cost : 

APEC  membership  fee  is  required.  There  is  also  a service 
charge  related  to  amount  of  program  use. 

6.  Human  Factors: 

Unknown 

7.  Turnaround : 

Unknown 
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8.  Documentation: 


User's  guide,  which  is  available  at  a cost  of  $25,  states  the 
program  operation,  engineering,  technical  aspects, 
appendix,  references  and  complete  instructions. 

9.  Scope : 

The  program  is  design  oriented  and  lends  itself  to  energy 
analysis  studies  only  by  way  of  definition  of  peak  load 
conditions.  Load  calculations  are  performed  on  a room-by- 
room basis.  Solar  load  calculations  consider  latitude, 
longitude,  daylight  saving  time  factors,  atmospheric 
clearness,  ground  reflectivity,  color  and  shading  devices. 
Cooling  calculations  are  performed  for  each  of  24  hours  and 
radiant  load  components  are  time  averaged  in  accordance 
with  building  mass. 

Design  goals  are  to  provide,  for  any  designated  geographical 
area  and  weather  system,  an  hour-by-hour  evaluation  of  the 
interrelating  effects  of  various  interior  conditions,  time- 
variable  interior  load  producing  sources,  and  building 
environmental  surfaces,  in  order  to  determine  peak  load 

conditions,  calculate  cfm  quantities,  and  arrive  at  actual 
system  loads  for  the  project  and  its  various  sub-parts. 

10.  Output : 

Complete  breakdown  of  all  input  factors,  and  cooling  and 
heating  peak  load  components. 

11.  Input : 

Room  data  for  each  master  room  indicating  room  dimensions, 
type  number  and  count  or  dimensions  of  all  exposed  surfaces, 
and  quantities  of  internal  load  producing  items  as  well  as 
any  special  override  factors  involved. 

12.  Logical  Structure: 

Unknown 

13.  Flexibility : 

Not  Obtained 

14.  Interfacing: 

Unknown 
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15.  Limitations: 


Primary  limitations  derive  from  the  relatively  small 
IBM/1130/8K  single  disk  computer  configuration  for  which 
the  program  was  actually  written,  and  are  related  to  project 
size. 

16.  Source  Language: 

Fortran  IV 

17.  Hardware  Implementation: 

IBM/1130  Systems  (8K  CORE,  1132  printer) 

18.  Portability: 

Unknown 

19 . Diagnostics : 

Unknown 

20.  Maintenance : 

By  Owner 

21.  Adaptability /Expandability: 

Unknown 

22 o Evaluative  Summary: 

The  major  limitations  of  HCC-III  in  usefulness  to  the  MIUS 
technical  effort  are  related  to  its  proprietary  nature  and  scope. 
Only  a computational  service  based  on  the  program  is  available, 
and  not  the  program  itself.  The  resultant  inability  to  verify  or 
adapt  program  algorithms  greatly  decreases  its  usefulness  as  a 
research  tool  for  MIUS.  Its  only  potential  use  would  be  in  a 
situation  where  it  had  computational  capabilities  not  otherwise 
available  in  a non-priprietary  program  in  the  possession  of  the 
MIUS  technical  staff.  Since  its  scope  is  limited  to  the 
calculation  of  peak  heating  and  cooling  loads  only,  this  is  not 
the  case. 


3.2  Trane  Air  Conditioning  Economics  Program  (TRACE) 


1.  Abstract : 

This  program  computes  energy  loads,  fuel  requirements,  and 
heating/cooling  system  costs  for  different  building  and 
mechanical  system  design  alternatives  up  to  a maximum  of  four 
per  run,  and  compares  the  results. 

2 . Author ( s ) ; 

Unknown 

3.  Owner ( s ) : 

The  Trane  Company 
LaCrosse,  Wisconsin 

4.  Availability: 

Proprietary;  used  through  Trane  engineering  representatives. 
Information  regarding  program  use  is  available  from  Trane  local 
offices . 

5 . Cost : 

$800/run  (four  building/system  design  alternatives). 

6 . Human  Factors : 

One  input  manual  is  completed  per  run  from  project  design  in- 
formation. Assistance  is  available  from  Trane,  and  the  input 
and  users  manuals  also  contain  clear  and  complete  detailed 
information.  Estimated  input  preparation  time  is  3 man-days. 
Completed  input  manual  is  sent  to  home  office  for  key  punching 
of  input  data  and  computer  batch  processing.  Output  is  returned 
by  mail. 

7 . Turnaround: 

Approximately  one  week  per  manual;  limited  by  mails  and  Trane 
keypunch  in  addition  to  computer  turnaround  time. 

8 . Documentation : 

Documentation  manual  [2]  and  input  manual  [3]  are  available 
on  request  from  TRANE. 

9 . Lie  ope  : 

Loads : Actual  weather  data  for  one  year  are  condensed  by  a 
special  procedure  Into  12  "typical  days",  one  for  each 
calendar  month  in  the  year.  Each  of  these  typical  days  con- 
sists of  a 24-hour  profile.  These  are  in  turn  used,  along 
with  recommended  ASHRAE  procedures  ( 1967 ) [4]  for  heating  and 
cooling  space  load  calculations.  Base  loads  are  included  by 
separate  schedules.  Simulation:  Eleven  common  air-side  systems 
are  simulated  (see  item  13),  primary  equipment  is 
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simulated  by  energy  performance  curves  that  are  functions  of 
the  demanded  output  of  the  equipment.  Performance  curves 
can  be  supplied  by  user,  or  in  the  case  of  some  equipment 
models  predetermined  performance  curves  can  be  accessed 
(mostly  Trane  equipment  models).  Financial  Analysis: 
Computes  annual  owning  and  operating  costs  for  each 
alternative  and  between  alternatives.  Computes  incremental 
payback,  and  present  value  rate  of  return. 


10.  Output : 

Besign  values,  monthly  fuel  usage  (water,  electricity,  etc.) 
economic  input  echo,  PITI,  depreciation  (tax  and  book),  cash 
flow,  P + L,  present  worth  of  total  owning  and  operating 
costs;  comparison  basis  P + L,  cash  flow,  cumulative  cash  flow, 
and  discounted  cash  flows  to  equity  and  first  cost. 

11.  Input : 

Room  design  conditions;  base  utilities  (per  schedule);  lights, 
people,  and  miscellaneous  (per  zone  per  schedule),  glass, 
wall,  shading  for  external  zones;  economic  input  (installed 
costs,  maintenance  cost,  depreciation,  mortgage  life,  and  so 
forth),  rate  structures;  air  side  input  (type,  economizer, 
usage  schedule,  etc.);  equipment  type  code  and  number  of  units. 

12.  Logical  Structure: 

Program  is  in  5 blocks  which  run  sequentially,  generating 
internal  files  to  feed  the  next  program.  Weather  data  and 
equipment  performance  are  read  from  tapes. 

13.  Flexibility : 

A maximum  of  four  alternative  schemes  can  be  analyzed  per 
run.  A maximum  of  ten  base  and  auxiliary  load  schedules 
can  be  input  per  alternative.  Each  alternative  can  have  up 
to  20  thermal  zones  and  one  or  two  air-side  systems  specified. 
The  following  air-side  systems  are  simulated; 

a.  High  velocity  variable  air  volume. 

b.  Low  velocity  variable  air  volume. 

c.  Double  duct 

d.  Multizone 

e.  Terminal  reheat 
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f.  Packaged  terminal  air  conditioner. 

g.  Hydronic  heat  pump. 

h.  Fan  coil. 

i.  Induction. 

j.  Radiation 

k.  Variable  temperature  constant  volume. 

14.  Interfacing: 

The  program  does  not  presently  interface  with  any  other 
software  systems. 

15.  Limitations : 

No  simulations  exist  for  T/E  plants  or  bulk  thermal  storage 
devices.  Due  to  the  remote  batch  processing  procedure, 
no  mid-stream  evaluation  is  possible. 

16.  Source  Language: 

Fortran 

17.  Hardware  Inplementation: 

Unknown 

18.  Portability: 

Unknown 

19-  Diagnostics: 

Unknown 

20.  Maintenance : 

Maintenance  by  The  Trane  Company  at  times  unknown. 

21.  Adap tability /Expandability : 

There  is  no  option  for  anyone  outside  of  the  Trane  Company 
to  adapt  or  expand  the  program.  Trane  plans  to  include 
other  equipment  (e.g.  other  manufacturers  and  T/E  models) 
at  some  indefinite  time  in  the  future. 

22.  Evaluative  Summary: 

TRACE  is  one  of  five  commercial  computerized  systems  considered 
in  this  report  which  accomplishes  a multi-step  total  project 
analysis  consisting  of  loads  determination,  mechanical  equip- 
ment simulation,  resultant  energy  requirements  determination, 
and  a comparative  economics  analysis  between  alternative 
systems.  Because  of  the  batch  mode  of  processing,  the  output 
of  one  analysis  section  is  automatically  input  into  the 
subsequent  one.  Therefore  no  midstream  evaluation  of  partial 
results  is  possible.  The  period  of  performance  analysis  is 
usually  taken  to  be  one  year. 
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Load  calculation  procedures  follow  ASHRAE  recommended 
procedures  (1967)  [U].  Although  weather  data  is  input 
for  the  whole  year  (8760  hours),  the  program  calculates 
from  this  data  twelve  "typical  weather  days"  (each  with 
values  for  2b  hours),  one  for  each  calendar  month.  All 
subsequent  monthly  energy  requirements  are  based  on  use 
of  the  same  "typical  weather  day"  profile  for  a whole 
month.  Building  loads  based  on  this  type  of  calculation 
are  less  suitable  for  determining  a prediction  of  actual 
energy  performance  than  they  are  for  determining  comparative 
energy  performance  of  different  mechanical  systems  (or  the 
same  system  controlled  in  different  ways),  for  the  same 
building  configuration. 

All  simulations  of  air-side  systems  and  mechanical  equipment 
performance  are  of  an  equilibrium  nature.  Part  load 
performance  curves  for  equipment  can  be  either  input  by 
the  user,  or  by  user  option,  some  are  available  on  computer 
files.*  A wide  range  of  total  system  configurations  can  be 
simulated  by  utilizing  appropriate  individual  simulations. 
Separate  scheduling  of  different  types  of  base  and 
auxiliary  loads  allows  for  close  reproduction  of  actual 
situation.  Total  energy  plant  configurations  and  thermal 
storage  devices  are  not  simulated. 

The  prime  limitation  with  respect  to  MIUS  use  of  this  pro- 
gram is  its  proprietary  nature.  It  is,  as  a result,  not 
subject  to  verification  of  the  exact  nature  and  validity  of 
its  algorithms  by  detailed  analysis  of  the  software.  In 
addition,  the  cost  of  use  as  a service  precludes  its  use 
as  a research  tool,  where  many  computer  runs  are  often 
necessary  to  complete  a specific  project  need. 


*Mostly  Trane  equipment 


3.3  Computerized  Evaluation  of  Energy  Requirements,  Equipment  Selection, 
and  Economic  Comparison  for  Building  Systems  (E-CUBE) 

1 . Abstract : 

For  a zone  or  a building  energy  system:  estimates  hourly, 
monthly  and  annual  energy  requirements,  determines  the 
energy  consumption  of  various  types  of  systems  which  may 
be  used  to  meet  those  energy  requirements,  compares  total 
owning  and  operating  costs  of  the  various  systems  being 
considered. 

2.  Author ( s ) : 

Contact  for  Technical  Matters: 

W.E. Evers,  Jr. 

Laclede  Gas  Company 
St.  Louis,  Missouri 

3.  Owner ( s ) : 

American  Gas  Association  (AGA) 

1515  Wilson  Blvd. 

Arlington,  Virginia  22209 

. Availability : 

Software  is  proprietary;  purchase  of  the  computational 
service  only  is  available,  either  directly  through  the  CDC 
CYBERNET  Network,  or  through  selected  local  gas  utilities. 
Previous  accounting  and  billing  procedures  have  to  be 
arranged  before  the  service  can  be  used.  User  information 
is  available  from  AGA. 

5.  Cost : 

Approximately  $50  for  a complete  analysis  including 
economic  comparison  (a  maximum  of  four  alternate  systems 
may  be  considered  for  a given  building). 

6.  Human  Factors : 

Engineering  knowledge  necessary  to  complete  input  data 
forms,  which  are  preformatted  and  come  with  instructions 
for  use. 

7.  Turnaround: 

Depends  on  mode  of  access.  Terminal  response  would  make 
this  mode  inherently  much  faster  than  batch  processing  mode. 

8.  Document at ion : 

A copyrighted,  complete  users  input  instruction  manual  is 
available  [5].  The  introduction  contains  short  qualitative 
descriptions  of  the  logical  structure  of  the  programs  and 
their  interrelationships. 
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9.  Scope : 


a.  Energy  Requirements  Program:  From  design  point 

values  for  thermal  and  base  electric  loads,  calculates 
hourly  loads  for  a weather  year  by  scaling  according 
to  variations  in  dry  bulb  and  dew  point  temperatures, 
solar  radiation,  and  cloud  cover.  Building  use  and 
operation  schedules  can  account  for  thermostat  set- 
back or  system  shutdown.  Building  thermal  storage 
and  delay  effects  are  considered.  Simultaneous 
heating/cooling  requirements  can  be  accounted  for. 

b.  Equipment  Selection  and  Energy  Consumption  Program: 

. Calculates  actual  energy  required  by  equipment  to 

meet  energy  requirements  calculated  in  (a).  Up  to 
four  different  plant  systems  can  be  evaluated  in 
each  run. 

c.  Economic  Comparison  Program:  Rate  of  return  cal- 

culation performed  for  each  plant  system  analyzed 
in  (b)  is  examined  comparatively. 

10.  Output : 

a.  A tape  with  hourly  thermal  and  electrical  loads;  a 
printout  of  peak  heating,  cooling,  electrical,  and 
process  loads  for  each  month  and  the  time  that  they 
occurred,  cumulative  values  of  loads. 

b.  Printout  of  monthly  summary  of  gas,  fuel,  electricity 
consumed;  peak  electric  demand;  number  of  operating 
hours  for  each  generator  and  chiller;  evaluation  of 
thermal  energy  usage. 

c.  Relative  to  the  cheapest  first-cost  system,  the 

following  differences:  annual  interest,  taxable 

income,  annual  tax,  after  taxes  cash  flow,  net  cash 
flow. 

11.  Input : 

a.  Design  point  (peak)  loads  and  base  electric  loads, 
weather  data,  solar  data,  occupancy  profiles,  system 
operating  schedules,  setback  schedules,  lighting 
and  process  load  profiles. 

b.  Fuel  heating  values,  system  characteristics,  generator 
schedule,  chiller  schedule,  equipment  performance 
data. 

c.  Initial  and  operating  cost  data,  tax  rates,  interest 
rates,  depreciation  rates,  irregular  annual  operating 
cost  data. 

12 . Logical  Structure: 

Modular. 

13.  Flexibility : 

This  program  contains  five  subroutines  which  are  used  to 
simulate  five  general  types  of  system  configurations.  The 
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detailed  performance  of  any  chosen  configuration  is  variable 
due  to  user  control  of  specific  equipment  performance  curves. 
The  five  configurations  are: 

a.  Total  Energy  System  with  Boilers. 

' b.  Total  Energy  System  with  Direct  Fired  Heater. 

c.  Conventional  System  with  Boiler. 

d.  Conventional  System  with  Direct  Fired  Heater. 

e.  All  Electric  System. 

14.  Interfacing: 

Not  Known 

15.  Limitations : 

Limited  as  to  the  maximum  number  of  input  schedules  and 
air-side  simulation  systems.  Limited  to  a maximum  of 
four  alternatives  per  run. 


16.  Source  Language: 

Fortran 

1 7 . Hardware  Implementation: 

CDC  6600 

18.  Portability : 

Not  Known 

19.  Diagnostics : 

Not  Known 

20.  Maintenance : 

By  Owner 

21 . Adaptability /Expandability : 

Unknown 

22.  Evaluative  Summary: 

This  program  is  another  which  falls  in  the  category  of 
offering  a complete  energy  analysis  of  a single  or 
multi-building  project,  from  building  loads  to  mechanical 
systems  energy  requirement  simulation,  to  utility  costs 
based  on  those  requirements,  to  economic  comparisons 
between  alternate  configurations.  The  period  of  performance 
analysis  is  usually  taken  to  be  one  year.  Thermal  load 
calculations  are  done  on  an  hourly  basis  for  this  entire 
period.  Transmission  loads  are  obtained  by  scaling,  according 
to  weather  conditions,  from  peak  load  values  and  their 
associated  weather  conditions,  whxch  must  be  supplied  to  the 
program.  Loads  based  on  this  type  of  calculation  are  less 
suitable  for  prediction  of  actual  energy  performance  than  they 
are  tor  determining  comparative  energy  performance  of  alternat 
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systems.  In  fact,  with  the  number  of  system  simulations 
(all  steady  state,  equilibrium  type)  limited  to  five  con- 
figurations (for  which  different  performance  data  may  be 
supplied  each  time  a run  is  made)  the  program  is  mostly 
limited  to  the  comparison  of  various  total  energy  con- 
figurations to  conventional  systems,  which  was  the  primary 
reason  for  its  development  by  GATE.- 

The  basic  limitation  with  respect  to  the  use  of  this 
program  for  the  MIUS  effort  is  its  proprietary  nature,  for  the 
same  reasons  that  were  discussed  in  the  previous  evaluative 
summary. 


'22 


3.4  The  Meriwether  Energy  System  Analysis  Series 


1.  Abstract 

Calculates  building  loads,  simulate  air  side  systems,  determine 
, energy  requirements  for  mechanical  and  electrical  components 
for  every  hour  of  the  year  and  make  annual  summary.  Also 
performs  economic  analysis  of  various  systems. 

2.  Author (s) : 

Ross  F.  Meriwether 

3.  Owner (s) : 

Ross  F.  Meriwether  & Associates,  Inc. 

1600  N.E.  Loop  410 

San  Antonio,  Texas  73209 

4.  Availability: 

Computer  Science  Corporation 
INFONET  System, 

University  Computing  System 

Time  sharing  as  well  as  batch  modes. 

5.  Cost : 

Depending  upon  the  extent  of  analysis,  it  could  be  as 
small  as  $10/run  or  as  large  as  $750/run. 

6.  Human  Factors: 

Nedd  comprehensive  knowledge  of  air-side  systems,  not  too 
easy  to  use  otherwise.  It  is  important  that  the  user 
understand  the  computer  system  simulations. 

Approximately  one  hour  is  required  for  data  preparation 
and  key  punch  per  zone. 

7.  Turnaround : 

1/2  to  1 minute  computer  execution  time  per  zone  per 
weather  year. 

8.  Documentation : 

No  algorithm  ever  published,  since  software  is  proprietary. 

A user's  manual,  available  only  from  the  program  owner,  has 
instructions  which  are  complete,  however. 

9.  Scope : 

The  heating  and  cooling  load  calculation  is  similar  to  Carrier 
manual  method.  Air-side  system  simulation  includes  terminal 
reheat,  induction  fan  coil,  dual  duct,  VAV  and  VAT.  It  can 
handle  gas,  oil,  electric,  total  energy,  and  heat  pump  systems. 

Hot  water  thermal  storage  can  also  be  simulated.  Utility  cost 
analysis  and  economic  comparison  programs  are  quite  comprehensive. 
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10.  Output : 

Detailed  output  as  well  as  selective  and  simpler  output  are 
possible.  Monthly  summary,  annual  summary,  space  summary  and 
system  summary  are  available  for  energy  consumption  as  well 
as  for  the  demand. 

11.  Input : 

Building  data  is  very  simple  but  system  data,  and  operational 
data  are  very  detailed.  Approximately  30  data  sheets  are 
attached  in  the  user's  manual. 

12.  Logical  Structure: 

Five  main  programs,  which  each  utilize  numerous  specialized 
subroutines,  are  run  sequentially  to  accomplish  a complete 
analysis.  The  names  of  these  program  blocks  are  descriptive 
of  their  functions  . 

a.  Energy  Requirements  Estimate  (ERE) 

b.  Total  Coincident  Requirement  (TCR) 

c.  Equipment  Energy  Consumption  (EEC/A, B) 

d.  Monthly  Utility  Costs  (MUC) 

e.  Economic  Comparison  of  Systems  (ECS) 

13.  Flexibility; 

Equipment  and  air-handling  systems  configurations  are  variable 
because  separate  types  of  equipment  have  separate  simulations 
which  can  be  linked  in  many  possible  ways.  The  air-handling 
system  simulations  available  are: 

a.  No  excess  cooling  or  reheating,  demand  coil 
leaving  temperatures. 

b.  Terminal  reheat  with  scheduled  (or  fixed)  cold 
coil  discharge  temperature  during  cooling. 

c.  Terminal  reheat  with  scheduled  (or  fixed)  cold 
coil  discharge  temperature  during  cooling  or 
heating. 

d.  Induction  or  fan-coil  type  system  with  scheduled 
primary  air  temperature. 

e.  Terminal  reheat  with  cold  coil  discharge  temperature 
set  by  maximum  demand  of  any  section. 

f.  Dual-duct  or  multi-zone  with  scheduled  (or  fixed) 
hot  and  cold  deck  temperatures. 

g.  Dual-duct  or  multi-zone  with  deck  temperatures  set 
by  greatest  demand. 

h.  Variable  volume  system  for  solar  and  internal 
loads,  with  separate  single-duct  system  to  offset 
transmission. 

i.  Standard  variable  volume  system. 

14.  Interfacing : 

It  has  been  interfaced  with  NBSLD  and  is  being  interfaced  with 
the  TACS  program  at  the  Dept,  of  Public  Works  of  Canada.  (See 
NBSRFM  data  form) . 
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15.  Limitations : 

Although  the  system  simulation  is  very  comprehensive  for  the 
conventional  system  analysis,  the  program  may  need  improvement 
for  the  accurate  temperature  simulation  of  heavy  structures, 
residential  buildings  and  other  non-convent ional  buildings. 

T/E  type  systems  are  not  simulated  per  se,  but  can  be 
"constructed"  from  the  individual  element  simulations.  The 
system  is  limited  as  to  the  maximum  number  of  building 
auxiliary  load  schedules  and  system  simulations,  even  though 
the  total  number  of  configurations  available  is  large. 

16.  Source  Language; 

Relocatable  files  on  INFONET-UNIVAC.  Source  language  is 
Fortran. 

17.  Hardware  Implementation: 

Univac  1108  System 

18.  Portability: 

It  is  on  time  sharing  files. 

19.  Diagnostics : 

Diagnostics  are  very  comprehensive  and  complete. 

20.  Maintenance : 

R . F . Meriwether 

21.  Adaptability/Expandability : 

Unknown 

22.  Evaluative  Summary: 

This  program  series  is  another  of  those  that  fall  in  the 
class  which  offers  a complete  energy  analysis  of  a single 
or  multi-building  project,  from  loads  determination  to 
energy  requirements  simulations  of  building  air-side  systems 
and  plant  equipment  systems,  to  utility  costs  estimates 
based  on  those  requirements,  to  economic  comparisons  between 
alternative  candidate  configurations.  In  this  series  mid- 
stream evaluation  of  results  is  possible.  The  period  of 
performance  analysis  is  usually  taken  to  be  one  year.  Thermal 
load  calculations  are  done  on  an  hourly  basis  for  this  period. 

In  this  particular  case,  the  transmission  loads  are  calculated 
by  scaling,  according  to  weather  conditions,  from  peak  values 
and  associated  weather  conditions,  both  of  which  are  supplied 
to  the  program.  Building  loads  based  on  this  type  of  calculation 
are  less  suitable  for  prediction  of  actual  energy  performance 
than  they  are  for  determining  comparative  energy  performance 
of  different  mechanical  systems  (or  the  same  system  controlled 
in  different  ways),  for  the  same  building.  All  simulations 
of  air-side  systems  and  mechanical  equipment  energy  perfor- 
mance are  of  a steady-state,  energy  balance  nature. 
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A wide  range  of  mechanical  and  plant  configurations  can  he 
simulated  by  construction  from  the  individual  simulations. 
Although  total  energy  systems  are  not  simulated  as  a single 
configuration,  some  types  are  constructable  from  the 
individual  equipment  simulations.  A simulation  of  a bulk 
hot  water  thermal  storage  system  is  available. 

The  prime  limitation  with  respect  to  the  MIUS  use  of  this 
program  series  is  its  proprietary  nature,  for  the  same 
reasons  that  have  been  discussed  in  earlier  evaluative 
summaries  in  this  report. 
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3.5  National  Bureau  of  Standards  Load  Determination  Program  (NBSLD) 

1.  Abstract: 

This  program  determines  building  heating  and  cooling  loads 
and  variations  of  the  interior  environment,  based  on  actual 
weather  data,  on  an  hour-by-hour  basis.  It  was  developed 
as  a research  tool  to  aid  in  the  thermal  design  of  buildings. 

2.  Author (s) : 

Dr.  Tamami  Kusuda 

Thermal  Engineering  Systems  Section 
Center  for  Building  Technology,  NBS 
Washington,  D.C.  20234 

3.  Owner (s)  : 

Public  (U.S.  Government) 

4 . Availability : 

Symbolic  source  decks  or  tapes  (in  either  BCD  or  ASCII  coding) 
available  on  request  for  the  cost  of  production.  Available  to 
all  Federal  government  workers  through  the  Computer  Sciences 
Corporation  INFONET  system  under  GSA  contract.  Further  avail- 
ability details  can  be  obtained  from  the  author. 

5.  Cost : 

Depends  on  costs  charged  by  a particular  computer'  center. 
Execution  time  is  4 minutes  per  zone  per  typical  weather 
year,  on  the  UNIVAC  1108,  EXEC-8  system  at  NBS. 

6.  Human  Factor: 

Input  data  form  available  and  although  straight  forward 
to  prepare,  it  is  detailed.  Output  has  option  of  either 
abbreviated  or  detailed  printout,  it  can  also  be  written 
on  magnetic  tape  for  later  use. 

7.  Turnaround : 

Processing  at  NBS  is  done  in  batch  or  time-sharing  mode. 

It  takes  about  one  hour  to  keypunch  data  for  the  first  zone 
in  a building,  additional  zones  are  10  minutes  each.  For 
execution  time  see  Item  5. 

8.  Documentation : 

A user’s  manual  is  available  as  an  NBS  Building  Science 
Series  publication.  Contents  include  description  of 
program,  listing  of  completed  program,  and  algorithms 
of  the  main  program  and  subroutines  [6]. 
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9.  Scope : 

The  program  will  compute  the  following: 

a.  Design  loads  based  on  a design  weather  cycle. 

b.  Hour-by-hour  loads  based  on  actual  weather  data 
of  any  locality,  for  a fixed  room  temperature 

or  a fixed  range  of  room  temperature  fluctuation. 

c.  Hour-by-hour  loads  based  on  actual  weather  data 
using  the  ASHRAE  "weighting  factor  method". 

d.  Room  temperature  hour-by-hour  fluctuation  when  limited 
or  no  heating  (and/or  cooling)  are  supplied,  and  a non- 
zero load  is  computed. 

10 . Output : 

a.  Abbreviated:  Response  factprs  for  walls;  daily  maximum 

and  total  cooling  and/or  heating  loads;  hour  of  occurance 
for  maximum  load. 

b.  Detailed:  Input  data,  response  factors  for  walls, 

hourly  dry  and  wet  bulb  temperature  (outside) , hourly 
inside  dry  bulb  temperature,  hourly  cooling  and/or 
heating  load,  and  daily  maximum  and  total  loads. 

11.  Input : 

a.  Schedules  of  lighting,  equipment,  and  occupant 
loads,  and  their  respective  maximum  values. 

b.  Locality  data  (longitude,  latitude,  weather  data 
tape,  time  zone,  etc). 

c.  Wall  construction  data  (number  of  layers,  thermophysical 
properties  of  each  layer). 

d.  Building,  zone,  or  room  dimensional  data. 

1 2 . Logical  Structure: 

Two  main  programs: 

a.  Main  program  to  decode  the  weather  tape  from 
Weather  Bureau  into  binary  code  and  put  onto 
tape. 

b.  Main  program  for  NBSLD  with  approximately  35 
subroutines  connected  to  the  main  program  or 
with  each  other  (See  Figure  1)  . 

1 3 . Flexibility : 

The  two  main  programs  above  can  either  be  run  separately,  or 
run  together  with  (a)  followed  by  (b) . Any  type  of  building 
with  known  construction  and  internal  heat  generation  can  be 

analyzed , 

14  „ Interfacing : 

Has  been  interfaced  with  Ross  Meriwether's  system  simulation 
and  economic  programs  package  directly  (see  following  NBSRFM  form). 
Also  could  be  used  as  input  for  any  specially  written  individual 
system  simulation  program. 
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15.  Limitations: 


a.  Apply  to  any  building  under  item  9 above,  types 
(a)  and  (c) . 

b.  Apply  to  any  building  which  can  be  divided  into 
rectangular  shaped  zones  for  item  9,  types  (b)  and 
(d). 

c.  Cannot  simulate  partial  exterior  shading  from  adjacent 
buildings,  trees,  hills. 

d.  Calculates  space  loads  only,  does  not  have  air-side 

or  plant  system  energy  simulations  as  an  integral 
part  (but  see  item  14). 

16.  Source  Language: 

Fortran  V 

17.  Hardware  Implementation: 

Main  program  for  load  computation  can  be  used  on  any  computer 
system  with  a core  memory  larger  than  50,000  words,  or  less 
if  overlay  or  segmentation  capability  is  available  in  the 
system.  Main  program  for  decoding  the  Weather  Bureau  type  can 
be  used  only  on  Univac  System. 

18.  Portability: 

Program  can  be  copied  into  BCD  code  on  another  tape  and 
recompiled  by  other  system's  Fortran  compiler. 

19.  Diagnostics : 

These  are  of  a limited  and  basic  nature. 

20.  Maintenance : 

Dr.  T.  Kusuda  is  responsible  for  the  updating  of  the  program 
with  the  assistance  of  Messrs.  J.  Hill,  S.  Liu,  and  J.  Barnett 
of  NBS. 

21.  Adapt ability /Expandability: 

Modification  of  the  program  (main  or  subroutines)  for  a 
particular  application  with  special  requirements  is 
straightforward. 

22.  Evaluative  Summary: 

NBSLD  was  specifically  developed  as  a research  tool  which, 
when  properly  applied,  can  accurately  predict  the  thermal 
loads  and  interior  space  conditions  of  a wide  variety  of 
building  design  configurations.  It  computes  loads  and  interior 
space  temperatures  on  an  hourly  basis,  usually  for  a complete 
weather  year  (but  can  be  for  any  part  thereof) , using  actual 
weather  data.  In  order  to  be  able  to  simulate  the  greatest 
possible  number  of  building  design  configurations,  the  thermal 
response  properties  of  the  building  structure  itself  are  cal- 
culated from  a detailed  description  of  the  thermophysical 
properties  of  the  structural  components  and  also  individual 
details  of  the  construction. 


External  effects  such  as  solar  loading  and  air  infiltration 
are  correctly  accounted  for.  One  shortcoming  in 
the  technical  aspects  of  the  load  calculations  done  by  NBSLD 
is  the  inability  to  account  for  shading  by  objects  external 
to  the  building  itself,  such  as  trees  or  other  buildings. 

This  last  factor  could  result  in  a major  overestimate  in  the 
cooling  load,  for  example,  of  a tall  building  which,  during 
sometime  period  each  day  is  largely  in  the  shade  of  an 
adjacent  building.  In  the  hands  of  a knowledgeable  user  who 
is  aware  of  this  limitation,  misapplication  of  the  program 
could  be  avoided. 

There  is  a trade-off  that  is  made  in  achieving  great  flexibility 
in  application:  The  amount  of  data  required  for  computation  is 
greater  than  for  other  programs.  Therefore,  the  amount  of  user 
effort  necessary  to  assemble  and  input  this  data,  and  the 
associated  probability  of  some  error  in  so  doing  is  correspon- 
dingly greater.  Another  factor  associated  with  the  program 
complexity  is  the  greater  amount  of  computer  execution  time 
required,  compared  to  other  programs.  There  is  no  .significant 
resultant  effect,  in  terms  of  human  factors,  however,  when 
computer  execution  time  is  on  the  order  of  minutes  instead  of  sec- 
onds. However f the  aspect  of  the  increased  execution  time  that 
would  be  significant  to  some  users  would  be  the  related  cost  of 
such  a system. 

The  effect  of  the  increased  execution  time  on  computer  costs 
is  for  the  most  part  not  significant  to  MIUS  agency  users  who 
would  implement  NBSLD  on  their  own  systems. 

The  lack  of  energy  requirement  simulations  for  building 
mechanical  systems  and  plant  equipment  is  the  major  limitation 
of  NBSLD  in  terms  of  its  usefulness  to  the  MIUS  effort.  In 
principle,  the  development  of  the  NBSLD/Meriwether  Energy 
System  Analysis  Series  hybrid  shows  that  this  limitation  can 
be  overcome.  In  practice,  however,  that  hybrid  (see  the 
related  Evaluative  Summary)  is  probably  not  the  best  final 
solution. 

As  a system  standing  by  itself,  the  primary  value  of  NBSLD 
to  MIUS  is  the  capability  it  can  provide  for  the  reliable 
verification  of  building  thermal  loads  for  specific  designs. 

This  capability  may  well  be  necessary  in  the  evaluation  process 
for  MIUS  demonstration  proposals.  In  any  use  of  NBSLD  by  the 
MIUS  effort,  the  assistance  of  its  author  in  guaranteeing 
its  proper  application  would  be  available. 
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3.6  rhe  Meriwether  Energy  System  Analysis  Series/NBSLD  Hybrid  (NBSRFM) 

1.  Abstract : 

This  hybrid  combines  the  load  calculation  capabilities  of 
NBSLD  with  the  system  simulation  capabilities  of  the 
* Meriwether  Energy  System  Analysis  Series. 

2.  Author (s) ; 

Ross.  F.  Meriwether 
T.  Kusuda  (NBS) 

3.  Owner (s) : 

Ross  F.  Meriwether  & Associates,  Inc. 

1600  N.  E.  Loop  410 
San  Antonio,  Texas  78209 

4.  Availability; 

Computer  Sciences  Corporation  INFONET  System  (time  sharing 
mode).  Contact  owner  for  information. 

5.  Cost ; 

By  special  arrangement  for  long  term  use  contracts  by 
government  agencies.  Similar  to  costs  of  Meriwether 
Analysis  alone  on  a per  run  basis. 

6.  Human  Factors : 

See  NBSLD,  Meriwether  sections  of  this  report. 

7.  Turnaround ; 

Approximately  the  sum  of  turnarounds  for  each  program 
system  separately. 

8.  Documentation : 

The  separate  user  manuals  are  sufficient  for  use  of  the 
hybrid  system,  with  additional  information  available  from  the 
owner. 

9 . Scope : 

The  hybrid  combines  the  capabilities  of  the  separate 
constituents . 

10.  Output : 

A combination  of  the  outputs  of  NBSLD  and  the  Meriwether 
Analysis  Series. 

11.  Input : 

The  sum  of  inputs  required  for  each  of  the  programs 
separately,  except  that  weather  and  building  thermal 
property  data  are  not  repeated. 
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12. 


Logical  Structure: 

NBSLD  replaces  the  load  estimation  function  that  is  a 
normal  part  of  the  Meriwether  system. 

13.  Flexibility: 

Combines  the  NBSLD  abilities  to  calculate  loads  for  a 
wide  range  of  building  configurations  with  the  flexibility 
of  the  Meriwether  air-side  and  equipment  simulations. 

lU . Interfacing: 

The  necessary  software  linkage  to  accomplish  the 
hybridization  exists  and  is  debugged. 

15 . Limitations : 

Same  as  for  each  system  separately. 

16.  Source  Language: 

Fortran.  Relocatable  Files  on  the  INFONET-Univac  system. 

IT . Hardware  Implementation: 

Univac  1108 

18 . Portability: 

Unknown 

19.  Diagnostics : 

Comprehensive 

20.  Maintenance : 

R.F. Meriwether 
T.Kusuda 

21 . Adapt ability /Expandability : 

Software  modifications  would  be  technically  straight 
forward. 

22 . Evaluative  Summary: 

Conceptually,  the  linkage  of  the  two  program  series  that 
comprise  this  hybrid  combines  the  complementary  capabilities 
of  both  into  a single  entity,  with  a concomitant  increase  in 
total  computational  power  and  flexibility.  In  particular, 
substitution  of  the  more  sophisticated  and  accurate  NBSLD 
in  place  of  the  Meriwether  load  estimating  procedure  improves 
the  capability  for  performing  predictive  analyses  of  actual 
energy  performances  which  is  a more  difficult  task  than  det- 
ermination of  an  optimum  configuration  by  the  comparative 
analysis  of  several  alternatives.  Along  with  the  increased 
capability  obtained  from  hybridization,  however,  there  is  a 
related  increase  in  effort  and  difficulty  in  its  use,  which  is 
approximately  the  sum  of  the  efforts  for  each  of  the  programs 
when  used  individually. 
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This  hybrid  also  occupies  a unique  position  regarding  its 
ownership  status  and  consequent  availability.  Because  one  of 
the  constituents  of  the  hybrid  is  proprietary,  the  whole  is 
in  effect  controlled  by  the  owner  of  that  constituent.  It 
therefore  suffers  (in  terms  of  usefulness  to  MIUS)  from  the 
same  shortcomings  of  any  such  program;  verification  of  program 
validity  by  direct  examination  of  the  software  is  not  possible, 
and  any  computational  services  of  the  hybrid  must  be  purchased. 

The  government  contract  with  the  owner  of  the  Energy  Systems 
Analysis  Series  (Meriwether)  under  which  the  hybrid  was  first 
made  operational  has  since  expired.  A need  to  make  the  hybrid 
available  for  MIUS  analysis  would  require  new  contractual 
arrangements  with  the  owner.  Because  of  the  problems  associated 
with  lack  of  access  for  program  verification,  if  a definite 
need  is  found  for  a substantial  amount  of  this  sort  of 
wide-scope  computational  analysis,  it  would  probably  be  more 
advantageous  for  the  MIUS  effort  to  obtain  or  develop  a set 
of  non-proprietary  system  simulations  to  link  up  to  NBSLD.  It 
should  be  noted  that  at  this  time,  none  of  the  existing 
government  developed  MIUS  type  simulations  have  the  configurational 
flexibility  of  this  hybrid. 
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3-7  Computer  Program  for  Analysis  of  Energy  Utilization  in  Postal 
Facilities  (TACS) , et  al. 

1.  Abstract : 

This  program  series  has  evolved  over  a period  of  several 
years.  There  are  four  identifiable  versions  of  it,  named 
as  follows: 

a.  Version  I - Computer  Program  for  Analysis  of 
Energy  Utilization  in  Postal  Facilities. 

b.  Version  II  - Unknown 

c.  Version  III  - Unknown 

d.  Version  IV  - Energy  Utilization  Analysis  of  Buildings 
Computer  Program. 

All  versions  calculate  heating/cooling  loads  and  simulate 
air-side  and  primary  systems  on  an  hourly  basis.  All  versions 
have  a separate  subprogram  which  performs  an  economic  analysis 
of  alternatives. 

2.  Author(s) : 

Met in  Lokmanhekim,  et  al. 

3.  Owner (s) : 

a.  Version  I - Public  (U.S.  Government) 

b.  Version  II  - General  American  Research  Division  (GARD)  of 
General  American  Transportation  Corp.  (GATX) 

Niles,  Illinois 

c.  Version  III  - Hittman  Associates,  Columbia,  Maryland 

d.  Version  IV  - Metin  Lokmanhekim 
Ellicott  City,  Maryland  21043 

4 . Availability : 

a.  Version  I - GARD/GATX  will  provide  a Fortran  source 
listing  on  magnetic  tape.  The  source  listing  is  also 
informally  available  on  request  from  several  user 
government  agencies. 

b.  Version  II  - Proprietary 

c.  Version  III  - Proprietary 

d.  Version  IV  - The  source  deck,  binary,  or  computational 
services  are  all  available  from  Metin  Lokmanhekim. 

5.  Cost : 

a.  Version  I - Source  tape  from  GARD/GATX 

about  $675.  Source  tape  from  government  agencies  at  cost. 
Cost  per  run  depends  on  user  facilities. 

b.  Version  II  - Unknown 

c.  Version  III  - Unknown 

d.  Version  IV  - By  negotiation. 

6.  Human  Factors: 

a.  Version  I and  II  - Input  data  is  required  zone  by  zone. 
Detailed  input  requires  knowledge  of  building  geometry 
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and  shading  and  takes  about  four  days  per  run  for 
the  familiar  user. 

b.  Versions  III  and  IV  - Data  may  be  input  in  blocks  and 
zone  by  zone.  Buildings  described  in  detail  require 
* two  days  of  input  data  preparation  by  an  experienced  user. 

Rough  estimates  of  energy  consumption  using  block 
inputs  only  require  four  hours. 


7.  Turnaround : 

Depends  on  user  facilities;  for  block  input  on  Version  IV, 
turnaround  is  about  two  days. 


8.  Documentation: 

A user's  manual  for  Version  I only  [7  ]. 


9.  Scope: 

All  versions  calculate  heating/cooling  loads  and  simulate 
air-side  and  primary  systems  on  an  hourly  basis.  Later  versions 
provide  more  equipment  simulations,  utilize  the  building 
response  factors  in  the  load  calculations  and  permit  internal 
temperature  variation.  Version  I calculates  the  response 
factors.  All  versions  include  a separate  subprogram  which 
performs  an  economic  analysis  of  alternatives. 


10.  Output : 

a.  Version  I - Building  heating  and  cooling  load  design 
hours;  maximum  and  minimum  heating  and  cooling  loads 
by  zone;  wall  and  roof  specification;  sensible,  latent, 
lighting,  and  electrical  loads  by  zone;  plots  of  the 
thermal  load  on  a daily,  weekly,  monthly,  or  yearly 
basis;  edited  thermal  loads  set  up  for  simulation; 
air-side  system  ratings  and  zone  air  flows;  summary 

of  equipment  sizes;  monthly  energy  requirements  by 
energy  type;  monthly  plant  water  requirements,  input 
economics  echo;  and  annualized  owning  and  operating  costs. 

b. '  Versions  II,  III,  and  IV  - Similar  output. 

11.  Input : 

a.  Version  I - Hourly  weather  data  (dry  - and  wet-bulb 
temperatures,  cloud  amount  and  type,  wind  velocity, 
and  atmospheric  pressure),  latitude,  longitude,  time 
zone,  infiltration,  load,  various  schedules,  surface 
coordinates  and  descriptions  for  each  surface  bounding 
or  shading  a zone,  number  and  type  of  plots,  design 
set  points  of  equipment,  type  of  air-side  systems, 
energy  types,  types  of  chillers;  capital  and  operating 
costs,  interest  rate,  lifetime,  and  purchased  energy 
rates. 
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b.  Version  II  and  III  - Unknown 

c.  Version  IV  - Building  data  can  be  input  in  blocks 
instead  of  surfaces  zone  by  zone;  surface  descriptions 
do  not  require  layer  U-values;  a greater  choice  of 
equipment  simulations  is  offered;  temperature  schedules 
are  permitted;  parametric  design  evaluation  requires 

a card  change. 

12.  Logical  Structure: 

a.  Version  I - Seven  subprograms  run  in  series  . 

b.  Versions  II  and  III  - Unknown 

c.  Version  IV  - Four  subprograms;  loads,  temperature 
variation,  systems  simulation,  and  economics. 

13.  Flexibility: 

a.  Version  I - The  program  can  handle  very  detailed 
building  information. 

Air-side  systems  are  single  zone,  multi-zone,  dual 
duct,  single  zone  reheat,  unit  ventilator,  unit  heater, 
and  floor  panel  heating.  Five  types  of  chillers  and 
four  energy  sources  are  allowed.  No  part-load  curves 
are  permitted. 

b.  Versions  II  - Unknown 

c.  version  ill  - Unknown 

d.  Version  IV  - In  addition  to  the  above,  two-  and 
four-pipe  fan  coil  units,  through-the-wall  units, 
split  system,  and  varying  volume  with  time  can  be 
simulated. 

14.  Interfacing: 

Versions  I and  IV  thermal  load  outputs  can  be  read  into 
the  AXCESS  program. 

15.  Limitations : 

a.  Version  I cannot  simulate  a T/E  plant  using  turbines 
or  anything  but  steam-based  cooling,  nor  can  it 
simulate  fan  coil  and  induction  units. 

b.  Version  IV  cannot  simulate  induction  units  and  has  the 
same  limited  simulations  of  T/E  systems. 

16.  Source  Language: 

All  versions  are  written  in  Fortran  IV.  Version  IV  is  also 
available  in  Control  Data  Fortran. 

17 . Hardware  Implementation: 

All  versions  are  operational  on  IBM  360  and  370  series,  CDC 
3600,64601,  6600  and  7600  series,  and  Univac  1108.  The  weather 
decoding  subroutines  is  machine  dependent  on  these  machines. 
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18.  Portability : 

The  program  is  very  portable  due  its  wide  application  base 
and  the  fact  that  everything  but  the  weather  decoding  routine 
is  non-machine  dependent. 

19.  Diagnostics : 

a.  Version  I - None 

b.  Version  II  - Unknown 

c.  Version  III  - Unknown 

d.  Version  IV  - Coded  printouts  but  no  accompanying 
manual;  logical  errors  cause  abortion  of  run. 

20.  Maintenance: 


a. 

Version 

I - None 

b. 

Version 

II  - Unknown 

c. 

Version 

III  - Unknown 

d. 

Version 

IV  - By  Metin  Lokmanhekim 

21.  Adaptability/Expandability: 

a.  Version  I - The  source  listing  may  be  expanded  by  the 
user. 

b.  Versions  II  and  III  - Potential  unknown. 

•c.  Version  IV  - By  user  if  source  has  been  obtained; 

•by  Metin  Lokmanhekim  if  negotiated. 

An  expanded  simulation  base  is  not  difficult  to  achieve  due 
to  modular  program  construction. 

22.  Evaluative  Summary: 

All  versions  of  this  program  offer  a complete  energy  analysis 
of  a single  or  multi-building  project,  including  load 
determinations,  air-side  system  simulations,  plant  equipment 
simulations,  and  annualized  owning  and  operating  costs.  A 
modular  series  program  structure  permits  midstream  evaluation 
of  results.  The  period  of  analysis  is  usually  one  year. 

All  calculations  are  performed  on  an  hourly  basis  in  an 
equilibrium  or  steady-state  simulation.  The  thermal  loads 
are  actually  computed  from  building  thermal  properties,  not 
scaled  as  in  the  Meriwether  program  series.  Building  loads  based  on 
these  calculations  are  suitable  for  prediction  of  actual  energy 
performance.  Simulations  of  a total  energy  plant  are  limited 
to  engines  with  steam  recovery  for  either  absorption  or  steam 
turbine  centrifugal  chillers.  Equipment  is  sized  on  the  basis 
of  the  peak  hourly  heating  and  cooling  loads,  and  no  part-load 
efficiencies  may  be  input. 

The  preparation  of  input  material  is  difficult  and  time  consuming 
for  all  but  the  single  block  analysis,  requiring  a two  to  four 
day  effort  by  competent  and  knowledgeable  engineers.  The  com- 
plexity of  the  input  process  increases  the  probability  of 
input  errors.  The  block  input  option  which  permits  quick 
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parametric  analysis  in  the  conceptual  design  is  only 
available  with  Versions  III  and  IV.  In  Version  I,  response 
factors  are  calculated  from  surface  descriptions  by  methods 
comparable  to  those  used  in  NBSLD.  The  internal  temperature 
set-point  may  be  varied  only  in  Version  IV.  The  number  of 
equipment  simulations  of  Version  1 is  limited,  but  expansion  of 
this  section  is  not  difficult. 

Versions  II,  III,  and  IV  are  proprietary,  and  suffer  the  same 
disadvantages  for  MIUS  use  mentioned  previously.  The  source 
deck  of  Version  I is  presently  in  the  possession  of 
several  participating  agency  teams,  and  though  the  source 
deck  of  Version  IV  is  available,  it  would  have  to  be 
purchased.  The  excellent  thermal  load  calculational  procedures 
of  this  program  and  limited  equipment  energy  simulation  base 
make  it  a prime  candidate  for  either  marriage  to  a program 
with  a strong  and  flexible  simulation  base,  or  for  use  by 
itself  with  the  development  of  the  most  likely  MIUS  plant 
equipment  simulations. 
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Alternate  Choice  Comparison  for  Energy  System  Selection  (AXCESS) 


1.  Abstract ; 

The  AXCESS  Energy  Analysis  Computer  Program  provides 
estimates  of  the  comparative  energy  uses  of  alternate  methods 
of  meeting  the  energy  requirements  of  buildings  or  processes, 
and  an  economic  analysis  of  the  alternatives. 

2.  Author  (s)  : 

For  technical  matters  contact: 

Edward  Douglass 
Computer  Applications 
Edison  Electric  Institute 

3.  Owner (s) : 

Edison  Electric  Institute 

90  Park  Avenue 

New  York,  New  York  10016 

4.  Availability : 

The  AXCESS  program  was  released  to  investor  owned  electric 
utilities  through  a nationwide  series  of  user  training 
programs  beginning  in  November  1972.  Each  of  these  companies 
has  been  furnished  with  a program  source  deck,  user's  manual 
sample  problem  and  help  in  achieving  implementation  on  its 

own  computer  AXCESS  is  also  available  to  these  utilities 

through  a remote  service  bureau.  Under  similar  conditions, 
it  has  also  been  made  available  to  MIUS  agency  participants. 

5.  Cost : 

Depends  on  user  system. 

6.  Human  Factors: 

Relatively  large  time  and  effort  requirements  for  preparation. 
One  run  batch  for  entire  energy  analysis. 

7 . Turnaround : 

Depends  on  user  system. 

8.  Documentation : 

a.  Engineering  Analysis :Users  manual  [si  and  a programmer's 
manual  [9]  are  available  on  request. 

b.  Financial  Analysis:  Users  manual  [10]  and  a programmer's 
manual  [11]  are  available  on  request. 

9.  Scope : 

The  program  uses  standard  engineering  principles  but  bases 
all  it  s calculations  on  input,  so  that  as  the  quality  of 
input  increases,  so  will  the  quality  of  the  output.  It  is 
well,  however,  to  remember  that  the  program's  purpose  is  to 
provide  a comparison  of  alternate  designs  and  the  results  for 
each  scheme  have  much  more  validity  when  reviewed  in  relation 
to  each  other.  39 


The  submetering  capability  allows  the  calculation  of  actual 
demand  contributions  of  incremental  loads  to  the  total  per- 
mitting alternate  fuel  source  capability  within  one  scheme. 

10.  Output : 

a.  Hourly  meter  reading:  usage  and  demand. 

b.  Hourly  deficit  or  excess  KW  and  KWH  if  the  T/E 
scheme  satisfies  the  load  first. 

c.  Day  by  day  meter  readings:  use  and  demand. 

d.  Time  of  day  of  occurrence  of  maximum  meter  reading. 

e.  Total  Btu  heat  rejected  from  all  chillers,  by  month. 

f.  Monthly  excess/deficit  of  heat. 

g.  Annual  excess/deficit  of  heat. 

h.  Net  Present  Value  or  Internal  Rate  of  Return. 

11.  Input : 

a.  Project  Description  data  including  building  operation 
schedules. 

b.  Base  load  items  of  usage  including  usage  profiles  and 
special  period  profiles. 

c.  Waste  heat  utilization-item  usage. 

d.  Heating/cooling  load  data. 

e.  Space  type  data. 

f.  Zone  description  data. 

g.  On-site  generation  system  performance. 

h.  Terminal  and  primary  system  description  including 

waste  heat  utilization  and  dual  fuel  operation 
description. 

i.  Meter  description  and  fuel  codes. 

j.  Capital  costs. 

k.  Maintenance  and  operating  costs. 

l.  Tax  rate. 

12 . Logical  Structure: 

Single  run  with  all  parameters  input  at  start,  modular 
program  structure  . 

13.  Flexibility : 

For  the  same  building,  with  the  same  usage,  the  program 
permits  simultaneous  comparison  of  up  to  six  alternate  methods 
of  meeting  the  energy  requirements.  Such  things  as  the  HVAC 
system  and  the  lighting  levels  may  vary  among  these  six 
"schemes",  while  the  building  occupancy  pattern  is  assumed 
to  be  the  same  for  each  scheme.  The  air-handling  and  plant 
system  simulations  available  are: 

a.  Dual  Duct. 

b.  Multi-Zone 

c.  Single  Zone  Reheat 

d.  100%  Variable  Volume 

e.  Variable  Volume  with  Reheat 

f.  Ceiling  Induction 
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g.  Heating  and  Ventilating 

h.  2-Pipe  Induction 

i.  4-Pipe  Induction 

j . 2-Pipe  Fan  Coil 

k.  2-Pipe  Unit  Ventilator 

l.  4-Pipe  Fan  Coil 

m.  4-Pipe  Unit  Ventilator 

n.  Unitary  Cooling  Units  with  Separate  Heating 

o.  Unitary  Heat  Pumps 

p.  Boilers 

q.  Furnace 

r.  Refrigeration 

s.  Simultaneous  Heat  Pumps 

t.  Changeover  Heat  Pumps 

u.  On-Site  Generation-KW  Balance 

v.  On-Site  Generation-Thermal  Balance 

14.  Interfacing: 

Presently  interfaced  with  TACS  (Version  I)  and  the  Lokmanhekim 
revision  (Version  IV)  of  the  Lokmanhekim  series. 

15.  Limitations : 

This  is  a tool  that  enables  the  designer  to  make  a 
comparison  of  various  designs,  not  to  generate  a design. 

While  the  program  makes  some  normal  design  assumptions  in 
the  event  of  a missine  incut _ it  aluavs  rpnnpst-s  t-ho  dpcion 
as  input. 

16.  Source  Language: 

Fortran 

17.  Hardware  Implementation: 

IBM  360  and  Univac  1108. 

18.  Portability : 

Moderately  Portable 

19.  Diagnostics : 

None 

20.  Maintenance : 

Software  revision  notices  sent  to  holders  of  software  by  owner. 

21.  Adaptability /Expandability : 

Since  the  Fortran  source  program  deck  is  available  and 
because  of  the  modular  structure  of  the  software,  expansion 
and  adaptation  of  the  program  to  model  MIUS  designs  is 
possible. 
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22.  Evaluative  Summary; 

This  program  series  offers  a complete  energy  analysis  of  a 
single  or  multi-building  project,  including  load  determinations, 
air-side  system  simulations,  plant  equipment  simulations,  and 
annualized  owning  and  operating  costs.  The  series  consists 
of  a complex  energy  analysis  program  and  an  independent  short 
financial  analysis  program.  Midstream  evaluation  is  not 
possible  in  either  program.  The  period  of  analysis  is  usually 
one  year. 

The  thermal  load  calculations  and  complete  energy  analysis 
are  accomplished  each  hour  before  proceeding  to  the  next 
hour.  Therefore  the  program  will  not  size  the  plant  equipment 
and  base  part-load  efficiencies  on  that  size.  All  calculations 
assume  steady-state  or  equilibrium  conditions.  As  in  the 
Meriwether  program  series,  the  thermal  loads  are  scaled  based 
on  design  loads  and  design  weather  conditions.  Building  loads 
based  on  these  calculations  are  suitable  for  comparison  of 
alternatives,  but  not  for  prediction  of  actual  energy  perfor- 
mance. Response  factors  may  be  input  (from  another,  program) 
or  default  values  for  light,  medium  and  heavy  construction 
may  be  utilized. 

The  air-side  and  plant  systems  simulation  package  is  one  of  the 
most  complete  of  the  program  series  surveved.  Addition  or 
adaptation  of  equipment  simulations  is  facilitated  by  the 
modular  package  structure.  Estimated  equipment  size  is  a 
required  input  for  part-load  performance  curves.  If  the 
demand  exceeds  capacity,  the  design  efficiency  will  be  used. 

The  preparation  of  input  material  requires  experience  and  time; 
one  to  three  days  for  experienced  engineers.  The  complexity 
of  the  input  process  increases  the  probability  of  input  errors 
or  meaningless  final  product.  A block  input  option  is  avail- 
able which  simplifies  the  input  process  for  conceptual  design 
evaluation. 

Though  this  program  is  proprietary,  the  source  deck  is  avail- 
able to  EEI  member  utilities  and  MIUS  participants  at  a 
reasonable  charge.  The  strong  and  flexible  simulation  base  of 
this  program  and  the  ease  of  block  input  for  conceptual  design 
analysis  made  it  a prime  candidate  for  MIUS  use.  It  will  provide 
an  excellent  base  for  simulation  of  a MIUS.  For  a detailed 
predictive  evaluation  of  energy  requirements  at  a specific  site, 
this  program  is  a prime  candidate  for  marriage  to  a program 
with  detailed  thermal  load  calculational  procedures. 
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3.9  TACS/Lokmanhekim/AXCESS 


1.  Abstract ; 

In  Version  I,  the  thermal  loads  computed  by  the  TACS  program 
are  input  to  the  energy  systems  simulation  subprogram  of 
AXCESS.  In  Version  II,  the  thermal  loads  computed  by  the 
Energy  Utilization  Analysis  of  Buildings  Computer  Program  are 
input  to  the  energy  systems  simulation  subprogram  of  AXCESS. 

2.  Author (s) : 

Authorship  of  the  individual  programs  has  been  previously 
mentioned.  The  interface  in  Version  I is  a part  of  the 
AXCESS  program.  The  interface  in  Version  II  was  written  by 
Met in  Lokmanhekim. 

3.  Owner (s) : 

Ownership  of  the  individual  programs  has  been  previously 
mentioned.  The  interface  in  Version  II  is  owned  by 
Southern  California  Edison. 

4.  Availability: 

As  previously  mentioned,  except  that  the  interface  in  Version 
II  is  also  proprietary. 

5.  Cost : 

As  previously  mentioned  for  the  individual  programs. 

6.  Human  Factors: 

As  previously  mentioned  for  the  individual  programs. 

7.  Turnaround : 

Depends  on  user  facilities. 

8.  Documentation : 

Version  I - The  interface  mechanics  are  in  the  AXCESS  documentation. 
Version  II  - Interface  documentation  unknown. 

9.  Scope : 

Version  I - The  thermal  loads  computed  by  the  Computer  Program 
for  Analysis  of  Energy  Utilization  in  Postal  Facilities  are 
input  to  the  energy  systems  simulation  subprogram  of  AXCESS. 

Version  II  - The  thermal  loads  computed  by  the  Energy  Utilization 
Analysis  of  Buildings  Computer  Program  are  input  to  the  energy 
systems  simulation  subprogram  of  AXCESS. 
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10.  Output : 

As  previously  mentioned  for  the  individual  programs. 

11.  Input : 

As  previously  mentioned  for  the  individual  programs. 

12.  Logical  Structure: 

Thermal  loads  from  either  program  mentioned  above  are  input 
to  the  energy  systems  simulation  subprogram  of  AXCESS.  The 
AXCESS  structure  is  followed  from  there. 

13.  Flexibility: 

Either  version  of  this  hybrid  provides  excellent  program 
flexibility.  Both  versions  offer  a great  number  of  energy 
systems  simulations.  Version  I precedes  the  simulation  with 
a detailed  calculation  of  loads.  Version  II  permits  block 
analysis  of  conceptual  designs  and  facilitates  the  parametric 
analysis  of  changes. 


14.  Interfacing: 

These  hybrid  programs  are  based  on  interfaces. 


15.  Limitations : 

These  hybrid  programs  suffer  the  limitations  previously 
mentioned,  of  those  portions  of  the  individual  programs 

which  are  used  in  the  hybrid. 


16.  Source  Language: 

As  previously  mentioned  for  the  individual  programs. 

17.  Hardware  Implementation: 

As  previously  mentioned  for  the  individual  programs. 


18.  Portability: 

As  previously  mentioned  for 


the  individual  programs. 


19.  Diagnostics : 

As  previously  mentioned  for 


the  individual  programs. 


20.  Maintenance : 

As  previously  mentioned  for  the  individual  programs,  with 
maintenance  of  the  interface  in  Version  II  by  Metin  Lokmanhekim. 


21.  Adaptability /Expandability: 

As  previously  mentioned  for  the  individual  programs. 


22.  Evaluative  Summary; 

These  hybrid  programs  provide  the  greatest  flexibility  of  any 
computer  program  series  investigated.  For  MIUS  use  the  thermal 
load  calculation  procedures  provide  a predictive  accuracy 
comparable  to  that  of  NBSLD.  Either  version  of  this  hybrid  can 
account  for  the  effects  of  shade  on  thermal  loads.  Version  II 
provides  the  flexibility  in  user  input  and  system  simulation 
which  facilitates  parametric  analysis  of  different  conceptual 
designs.  Version  I is  not  proprietary  and  could  be  implemented 
with  a minimum  of  effort  since  both  constituent  programs  are  in 
the  possession  of  agency  participants,  and  AXCESS  can  be  easily 
modified  to  create  the  necessary  linkage.  Although  version 
II  is  proprietary,  a source  deck,  including  the  interface  could 
be  purchased.  The  two  versions  of  this  program  and  NBSRFM 
provide  greater  configurational  flexibility  than  any  of  the 
existing  MIUS  type  simulations  developed  by  the  government. 
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3.10  ORNL  BIN  Program 


1.  Abstract : 

The  BIN  program  estimates  and  compares  fuel  requirements  for 
the  total  energy  system  described  in  0RNL-HUD-MIUS-6  pL2  ] with 
the  fuel  requirements  of  a conventional  fossil-fuel  power 
system  when  supplying  identical  consumer  loads.  Related 
sub-programs  are  HEATEN,  C00LEN,  and  S0LAIR. 

2.  Author  (s) : 

C.  L.  Segaser, 

Oak  Ridge  National  Laboratory  (ORNL) 

Oak  Ridge,  Tennessee 

3.  Owner (s) : 

The  HUD  effort  at  ORNL  is  sponsored  by  the  U.S.  Department 
of  Housing  and  Urban  Development  under  HUD  Interagency 
Agreement  No.  1AA-H-40-72. 

4.  Availability: 

This  program  and  the  hourly  program  are  currently  stored 
on  disks  in  the  ORNL  PDP-10  time-sharing  computer  under 
the  subject  file  names. 

5.  Cost : 

The  algorithm  tor  charges  on  the  PDP-10  are  based  on  three 
features : 

Connect  Time  - $4  per  hour. 

Input/Output  - $0.01  per  128  input  or  output  requests. 

Core  Seconds  - $10  per  hour  per  IK  or  core  used. 

(These  charges  are  only  for  the  ORNL  system). 

6.  Human  Factors: 

Input  data  is  easily  prepared  and  may  be  punched  on  paper 
tape  prior  to  reading  in  the  data.  The  output  is  in  the 
form  of  readily  interpretable  tables.  No  useless  numbers 
are  printed  out. 

7.  Turnaround : 

Results  are  available  within  about  15  minutes  following  the 
input  of  data  when  the  RUN  command  is  typed  into  the  PDP-10 
time-sharing  system. 

8.  Documentation : 

The  BIN  program  is  described  in  a memorandum  report  under  the 
subject  Computer  Program  for  the  Thermodynamic  Analysis  of  a 
Total  Energy  System  []3  ].  It  contains  a general  description  of 
the  thermodynamic  basis  of  the  program,  including  an  energy 
flow  diagram,  the  input  data  format,  and  a description  of  the 
program  output. 

The  HEATEN  [14],  C00LEN,  and  S0LAIR  [15],  sub-programs  are 
similarly  described  in  ORNL  intra-laboratory  memoranda. 
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9.  Scope: 

The  BIN  program  analyzes  the  modular  integrated  utility  system 
shown  diagrammatically  in  Figure  2 . 

It  computes  and  compares  the  fuel  requirements  for  this  system 
with  the  fuel  requirements  of  a conventional  system  when  used  to 
supply  identical  electrical,  domestic  hot  water,  space  heating, 
and  air  conditioning  loads  to  consumer  models.  The  BIN  program 
uses  as  part  of  the  input  data  the  outputs  of  the  sub-programs 
HEATEN,  C00LEN,  or  S0LAIR.  The  HEATEN  program  estimates  the 
space  heating  energy  requirements  of  the  consumer.  The  C00LEN 
and/or  S0LAIR  programs  are  used  to  estimate  the  consumer  space 
cooling  energy  requirements.  These  sub-programs  utilize  temp- 
erature frequency  occurrence  (bin)  data  from  Chapter  6 of  the  Air 
Force  Manual  AFM-88-8  [16  ) or  as  compiled  from  National  Weather 
Records  Center  Data. 


10.  Output : 

The  BIN  program  presents  the  results  of  the  analysis  for  each 
month  of  the  year  by  means  of  several  tables. 


a. 

Table 

b. 

Table 

c. 

Table 

d. 

Table 

e. 

Table 

f. 

Table 

g- 

Table 

h. 

Table 

i. 

Table 

Consumer  loads. 

System  loads  at  the  central  equipment  building. 
Required  makeup  by  auxiliary  boiler  and 
engine  waste  heat  unused. 

Air  conditioning  load  to  motor-compressor 

and  absorption  chiller. 

Total  electrical  load  on  engine  generator. 

Fuel  requirements  for  the  T/E  system. 

Total  conventional  system  loads. 

Fuel  requirements  for  the  conventional  system. 
Comparison  of  T/E  system  fuel  consumption  with 
conventional  system  fuel  consumption. 


11.  Input : 

Fifteen  (15)  data  statements  are  required  for  the  BIN  program 
including  the  following  input  quantities: 

a.  Number  of  consumer  dwelling  units. 

b.  Yearly  hot  water  heating  load. 

c.  Yearly  electrical  load. 

d.  Hot  and  cold  water  pipe  line  transmission  loss. 

e.  Quantity  of  refuse  burned  in  auxiliary 
incinerator-boiler,  if  any. 

f.  Heat  content  of  refuse. 

g.  Factor  to  allow  for  added  fuel  for  complete 
combustion. 

h.  Consumer  complex  auxiliary  electric  load. 

i.  Monthly  central  equipment  building  auxiliary 
electric  load. 

j.  Monthly  space  heating  load  (output  of  HEATEN  program). 

k.  Monthly  electricity  usage  as  percent  of  total 
yearly  load. 
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l.  Monthly  air  conditioning  load  (output  of  C00LEN 
or  S0LAIR  program). 

m.  Monthly  domestic  hot  water  usage  as  percent  of  total 
yearly  load. 

n.  Monthly  ceiling  on  beneficial  use  of  waste  heat. 

o.  Efficiency  of  motor  compressor  refrigeration  system. 

p.  Efficiency  of  engine-generator  for  electrical  load. 

q.  Type  of  fuel  burned  in  engine  and  auxiliary  boiler. 

r.  Efficiency  of  auxiliary  boiler  in  total  energy  system. 

s.  Heating  value  of  fuel. 

t.  Monthly  auxiliary  electric  load  for  conventional  system. 

u.  Efficiency  of  boiler  for  space  and  hot  water 
heating  in  conventional  system. 

v.  Central  station  plant  efficiency  in  conventional  system. 

w.  Heating  value  of  fuel  used  in  conventional  system. 

12.  Logical  Structure: 

The  complete  system  consists  of  several  independent  programs 
(HEATEN,  C00LEN , or  S0LAIR ) which  must  be  run  to  compute 
the  space  heating  and  space  cooling  energy  requirements. 

The  outputs  of  these  programs  are  then  used  as  input  to  the 
main  BIN  program,  which  consists  of  approximately  200 
statements . 

13.  Flexibility: 

Although  the  programs  are  specifically  designed  to  analyze 
a total  energy  system  similar  to  Figure  7 and  compare  its 
fuel  requirements  to  a conventional  system,  the  programs 
can  also  be  used  to  analyze  variations  of  the  total  energy 
system  by  assuming  appropriate  values  for  the  program  input 
parameters.  The  programs  have  been  applied  to: 

a.  A total  energy  system  in  which  all  electricity, 
space  heating  and  cooling,  and  domestic  hot  water 
are  supplied  to  the  consumer  from  an  equipment 
building  located  on-site. 

b.  A T/E  sysgem  similar  to  A except  that  the  entire 
cooling  capacity  is  provided  by  absorption  refrigeration 
system  chillers. 

c.  The  HEATEN  and  C00LEN  programs  can  be  applied  to  the 
analysis  of  conventional  heat  pump  systems. 

d.  A conventional  district  system  in  which  electricity 
is  purchased  from  a regional  utility  system. 

e.  A T/E  system  in  which  a part  of  the  fuel  burned  in 
the  auxiliary  boiler  consists  of  solid  wastes. 

f.  Various  sensitivity  studies  in  which  the  effect  of 
varying  different  input  parameters  on  fuel  consumption 
can  be  analyzed. 

l4 .  Interfacing : 

The  BIN,  HEATEN,  C00LEN,  and  S0LAIR  programs  are  all  written 
in  BASIC  language  for  the  time-sharing  PDP-10  computer  at 


48 


ORNL. 


15.  Limitations : 

The  following  quotation  presents  several  limitations  of  the 
"bin"  method  for  estimating  heating  and  cooling  load  energy 
requirements  [17]: 

"While  the  basic  bin  method  provides  for  load  calculations 
at  various  temperatures  and  at  some  variation  in  operating 
conditions,  it  still  assumes  that  internal  load  and  solar 
radiation  load  are  constant  during  the  operating  period 
covered  by  the  temperature  bins.  This  drawback  can  be  over- 
come somewhat  by  establishing  temperature  bins  on  5 F deg 
and  1-hr  increments  instead  of  8-ht  increments.  This  would 
allow  the  internal  load  to  be  varied  each  hour  of  the  day 
and  matched  to  the  solar  load  for  that  hour.  However,  this 
does  not  permit  various  types  of  occupancy  and  operational 
days  during  the  month.  Other  factors  which  the  bin  method 
is  not  able  to  accommodate  are  latent  heat  load  variations 
and  the  effect  of  heat  storage  and  release  during  periods 
of  setback  or  shutoff.  A computerized  version  of  the  bin 
method  permits  the  use  of  small  increments  and  many  sets  of 
operating  over  the  degree-day  method  or  equivalent  full-load 
hours  methods." 

16.  Source  Language: 

BASIC 

17.  Hardware  Implementation: 

PDP-10  at  ORNL 

18.  Portability: 

Punched  tapes  can  be  prepared  of  the  programs  and  used 
wherever  there  is  a compatible  time-sharing  computer  system. 

19.  Diagnostics : 

Errors  in  command,  compliation  of  data,  or  in  execution 
are  recognized  and  the  appropriate  diagnostic  message 
is  immediately  typed  out  by  BASIC. 

20.  Maintenance : 

The  maintenance  of  the  software  is  done  by  the  author  of 
the  various  programs  (C.  L.  Segaser)  and  changes  in  the 
programs  are  made  as  necessary. 

21.  Adapt ability /Expandability: 

Changes  or  additions  to  the  software  in  BASIC  are  easily 
accomplished  by  simply  changing  or  deleting  statements  and 
adding  additional  statements  as  required. 


22.  Evaluative  Summary: 

The  ORNL  BIN  Program  was  an  early  development  at  that  agency 
for  the  purpose  of  comparative  energy  performance  evaluation 
of  MIUS  utility  delivery  configurations  versus  conventional 
configurations.  Since  that  time  an  hourly  analysis  program 
(described  in  the  following  section) , with  more  sophisticated 
and  accurate  load  determination  procedures  and  some  improvements 
and  additions  to  the  steady-state  energy  simulations  has  been 
developed  by  ORNL.  Because  of  this  subsequent  development, 
the  BIN  program  has  been  effectively  superseded. 
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3.11  ORNL  1973  MIUS  Comparative  Energy  Analysis  Program 


1.  Abstract : 

Uses  hourly  weather  tapes,  generalized  building  description 
data,  hourly  consumption  data  on  electricity  and  water,  desired 
indoor  temperature  and  humidity  schedules , and  machinery  per- 
formance data  to  calculate  relative  space  heating  and  cooling 
loads,  heating  and  chilling  coil  loads,  fuel  requirements  and 
components  thereof  for  different  MIUS  applications  compared  to 
conventional  systems  on  an  hourly,  monthly,  or  annual  basis. 

Uses  algorithms  in  1972  (ASHRAE  Fundamentals  Handbook  [ 1 8]  . 

2.  Author (s) : 

John  V.  Wilson, 

Oak  Ridge  National  Laboratory, 

Oak  Ridge,  Tennessee 

FTS  (615)  483-7622  or  (615)  483-8611,  ext.  3-7622. 

3.  Owner (s) : 

Public  domain. 

4.  Availability : 

Although  this  program  was  intended  solely  for  internal  use 
and  is  not  formally  documented,  all  or  part  will  be 
made  available  upon  request  if  approved  by  the  sponsor 

( HUD-MIUS  pro j ect ) . 

5.  Cost : 

Cost  of  obtaining  cards  or  tape  is  only  service  charge  for 
copying  and  mailing  - estimated  $25  or  less  depending  on  mate- 
rial desired.  Run  time  is  6 seconds  per  weather  year  per 
Building  type  on  IBM  360/91,  or  30  seconds  per  weather  year 
per  building  type  on  IBM  360/75.  Consulting  services  for  running 
the  program  could  probably  be  arranged. 

6.  Human  Factors: 

Each  building  type  requires  two  cards  of  general  data 
such  as  areas,  four  cards  of  heat  transfer  functions 
selected  from  ASHRAE  tables,  and  22  cards  with  hourly 
schedules  for  occupancy,  water  use,  electricity  use, 
etc.  As  many  as  15  building  types  may  be  included. 

Three  additional  cards  containing  holiday  designations, 
machinery  data,  and  solid  waste  burning  data  for  the 
project  as  a whole  are  also  needed. 

Output  is  labelled  only  enough  for  internal  use,  and 
is  frequently  changed  for  requirements  of  the  occasion. 

More  output  is  printed  than  is  normally  required  for 
any  one  specific  study  or  application. 

7 . Turnaround : 

For  internal  use  results  are  normally  available  in  less 
than  one  working  day.  Jobs  can  be  submitted  by  messenger 
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service,  remote  terminal,  or  teletype. 


8.  Documentation : 

No  user's  manual  is  available  or  planned.  A program  descrip- 
tion is  given  in  Appendix  B of  reference  [19].  Since  the 
program  closely  follows  the  ASHRAE  Fundamentals  Handbook  for 
most  of  its  length,  a user  possessing  that  handbook  should  have 
little  difficulty  following  the  calculations. 

9.  Scope: 

This  computer  program  is  intended  for  use  in  calculating  relative 

energy  and  fuel  requirements  for  different  utility  systems 
and  development  projects  being  studied  in  the  HUD-MIUS 
project.  For  each  conceptual  type  of  building,  space 
heating  and  cooling  requirements  are  calculated  hourly  using 
weather  data  from  tapes  and  building  data  and  occupancy  or 
usage  schedules  provided  as  input  data.  The  algorithms  in 
the  1972  ASHRAE  Fundamentals  Handbook  are  used  [18].  From 
these  requirements  and  the  temperature  control  schedule  the 
heating  or  cooling  coil  loads  are  calculated.  From  these  in 
turn  the  hourly  operating  requirements  for  an  engine  generator, 
an  auxiliary  boiler  (which  may  burn  solid  waste),  an  air 
conditioner  of  either  absorption  or  motor-driven  type,  and 
for  heat  rejection  are  calculated.  Finally,  the  fuel  requirements 
ror  eacn  nour  are  caicuiacea.  Kesuics  are  summed  ana 
printed  for  selected  time  periods. 

10.  Output : 

Input  data  are  echoed  with  terse  identifications.  Some  or 
all  of  the  following  are  output  for  intervals  selected  by 
the  user: 

a.  Electric  load. 

b.  Space  heating  load. 

c.  Space  cooling  load. 

d.  Hot  water  heating  load. 

e.  Heater  coil  load. 

f.  Chiller  coil  load. 

g.  Absorption  chiller  Btu. 

h.  Motor-compressor  chiller  KWH. 

i.  Total  generator  load  KWH. 

j.  Auxiliary  boiler  Btu. 

k.  Heat  rejected  Btu. 

l.  Fuel  used. 

Components  of  the  space  heating  load  owing  to  transmission, 
ventilation,  electric  usage,  occupants,  solar  radiation, 
and  humidity  control  may  be  printed  if  desired.  Various 
other  outputs  are  printed  from  time  to  time  for  specific 
investigations  by  program  changes. 
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11.  Input : 

For  each  building  type  the  input  data  are:  a.  Floor  area  and 
associated  heat  transfer  function  coefficients,  b.  Roof 
area  and  associated  heat  transfer  function  coefficients,  c. 
Window  area  and  associated  area  and  heat  transfer  coefficient. 

Hourly  schedules  for  both  ‘'occupied"  and  "unoccupied"  status 
for  each  of  the  following: 


a.  Shading  coefficient. 

b.  Inside  temperature. 

c.  Inside  humidity. 

d.  Occupancy. 

e.  Hot  water  heating. 

f.  Interior  electricity. 

g.  External  auxiliary  electricity. 

h.  Ventilation/infiltration. 

For  the  whole  system  data  include: 


a.  Holiday  schedule. 

b.  Machinery  capacities  and  efficiencies. 

c.  Solid  waste  burning  data. 

d.  Latitude  and  longitude. 

e.  Various  option  selectors  and  calculational  controls. 


12.  Logical  Structure: 

Program  consists  of  one  main'  program  of  about  350  Fortran 
statements  and  twelve  specialized  sub-routines,  plus  standard 
library  functions.  The  whole  comprises  about  1000  cards. 

The  main  program  is  very  simple  logically  but  is  long  because 
of  various  tallies  and  sums  that  are  zeroed,  incremented,  and 
printed,  and  because  it  prints  some  of  the  input  echo  and  some 
of  the  final  output. 

13.  Flexibility : 

The  system  can  handle  a MIUS  or  a total  energy  system 
or  a conventional  system  consisting  of  up  to  15  types 
of  buildings.  The  user  will  have  to  interpret  the 
printed  output  in  various  different  ways,  however,  to 
achieve  these  results. 


14.  Interfacing : 

Most  of  the  specialized  subroutines  could  probably  be 
used  almost  unchanged  in  a merger  with  another  system. 
Probably  at  least  half  of  the  main  program  would  have 
to  be  completely  rewritten. 
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15.  Limitations ; 

The  program  provides  only  a simplified  model  of  a con- 
ceptual type  of  building.  The  program  does  not  calculate  heat 
transfer  function  coefficients  from  basic  materials  properties 
data  as  NBSLD  does,  but  rather  must  have  these  coefficients 
provided  in  the  input  data.  The  program  does  not  include  models 
of  different  ventilation  systems. 

16.  Source  Language: 

IBM  Fortran  IV 

17.  Hardware  Implementation: 

IBM  360/75  and  360/91. 

18.  Portability ; 

In  principle,  it  should  be  easy  to  convert  this  program 
to  ASA  Fortran  or  Fortran  V,  since  Fortran  IV  is 
supposedly  a subset  of  Fortran  V.  No  doubt  some  problems 
would  arise  in  handling  format  statements  owing  to 
different  word  lengths  in  different  computers,  and  owing 
to  some  variations  in  names  of  library  functions. 

19.  Diagnostics : 

No  significant  diagnostics  are  provided. 

20.  Maintenance : 

The  author  is  using  the  program  frequently,  and  changes 
and  updates  it  frequently  as  various  new  demands  arise. 

21.  Adaptability/Expandability : 

The  program  logic  is  comparatively  simple  and  changes/additions 
should  be  no  more  difficult  than  for  the  typical  Fortran 
program. 

22.  Evaluative  Summary: 

The  ORNL  1973  MIUS  program  is  one  of  four  programs 
discussed  in  this  report  which  were  developed  specifically 
around  a MIUS  type  of  energy  performance  simulation.  Its 
purpose  has  been  for  comparative  analysis  of  different  systems 
based  on  energy  requirements.  At  this  time,  no 
economic  analysis  is  performed.  Program  content  consists 
of  a building  loads  determination,  and  a subsequent 
steady-state  energy  requirements  simulation  for  a typical 
MIUS  plant  configuration.  Building  thermal  loads  are  calculated 
on  an  hour-by-hour  basis  and  are  based  closely  on  procedures 
recommended  in  the  1972  ASHRAE  Handbook  of  Fundamentals  [18], 
Base  and  auxiliary  loads,  including  thermal  requirements 
for  hot  water  heating  are  calculated  according  to  input 
schedules.  Building  orientations,  for  purposes  of  solar 
loading  calculations,  are  set  up  in  a fixed  manner,  for 
both  single  and  multi-building  configurations,  and  can  be 
changed  only  by  internal  modification  of  the  program  itself. 

Because  of  the  lack  of  energy  performance 
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simulations  for  air-side  systems,  the  program  cannot  model,  in 
the  same  building  in  the  same  hour,  simultaneous  heating  and  cool- 
ing loads.  It  can  model  simultaneous  heating  and  cooling  loads 
only  in  different  buildings  in  a particular  hour.  In  a given 
building,  it  can  account  for  a change  from  heating  to  cooling  (or 
vice-versa)  from  one  hour  to  the  next.  This  limits  program 
analysis  capability  mostly  to  hypothetical  building  project 
configurations,  since  it  could  not  correctly  model  many  existing 
types.  All  these  considerations  suggest  that  the  lodds  pro- 
duced by  this  program  are  limited  in  suitability  to  comparative 
analyses  of  plant  systems  designed  to  satisfy  these  loads,  and 
not  actual,  realistic  predictions  of  actual  performance.  It 
should  be  noted  that  ORNL  has  mentioned  this  point  in  a descrip- 
tion of  the  program  [ 19 ] . In  the  present  program  then,  the 
model  assumes  that  the  total  building  thermal  loads  are  found  each 
hour,  and  with  a correction  estimate  for  distribution  losses,  are 

applied  directly  as  the  necessary  thermal  energy  requirements 
that  the  plant  system  must  modify.  The  ORNL  program  energy 
system  simulation,  to  which  the  loads  are  applied,  consists 
of  only  one  typical  MIUS  configuration:  a total  energy  plant 

with  addditional  features  of  incineration  heat  recovery  and 
thermal  storage,  feeding  a district  heating  and  cooling  system 
(Figure  2 and  reference  [20]).  Any  alteration  in  this  simulation 
would  have  to  be  accomplished  by  internal  program  modification. 

There  is  thus  a resultant  lack  of  user  flexibility  in  the  application 

of  this  program.  The  energy  performance  simulation  is  of  a 

steady-state,  equilibrium  nature,  and  calculations  are  made 

on  the  same  hourly  basis  as  the  thermal  loads  supplied  to  the 

plant.  Energy  conversion  models  used  for  plant  equipment  in 

the  simulation,  except  for  the  heat  recovery  power  generation, 

uses  fixed  conversion  efficiencies,  which  are  less  adequate 

than  models  which  employ  part  load  performance  data  for 

equipment.  The  resultant  simplicity  of  this  simulation 

compared  to  the  complex  performance  of  real  equipment  makes 

this  energy  simulation  less  suitable  for  prediction  of 

actual  performance  than  for  comparative  analyses. 

On  the  basis  of  the  preceding  discussion,  the  ORNL  1973  MIUS 
program  seems  to  be  best  suited  for  conceptual  level  estimates 
of  comparative  energy  feasibility  of  a MIUS  configuration  with 
different  performance  factors.  It  would  be  most  suitable  to 
compare  these  results  with  similar  calculations  for  a con- 
ventional utility  configuration  responding  to  the  same 
demands,  something  which  is  not  done  automatically.  This 
program,  in  its  present  form,  could  not  be  expected  to  accurately 
predict,  on  a reliably  consistent  basis,  actual  energy 
performance  of  a variety  of  real  systems,  due  to  the  limitations 
discussed  above.  It  is  therefore  of  little  use  in  the  evaluation 
of  real  system  designs.  At  this  time,  no  economic  analysis 
is  performed. 
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3.12  Energy  Systems  Optimization  Program  (ESOP) 


1.  Abstract: 


The  ESOP  was  written  primarily  for  the  purpose  of  predicting 
energy  consumption  of  a MIUS  system,  including  solid  waste, 
water  treatment,  power  generation,  and  comfort  conditioning. 

2.  Author ( s ) : 

The  Urban  Systems  Project  Office,  Johnson  Space  Center,  NASA 

and  the  Lockheed  Electronics  Company 

Allen  E.Brandli,  USPO-JSC,  Technical  Monitor 

3 . Owner ( s ) : 

National  Aeronautics  and  Space  Administration 
k.  Availability: 

National  Aeronautics  and  Space  Administration 
Urban  Systems  Project  Office 
Johnson  Space  Center,  Houston,  Texas 

5 . Cost : 

Unknown 

6.  Human  Factors : 

Variable  input  options  are  possible.  Those  parameters  not 
input  are  assumed  to  be  zero.  There  is  a total  of  less 
than  100  parameters  in  the  input  list  covering  all  phases 
of  MIUS  simulation.  Output  is  straightforward  and  easy  to 
read. 

7 . Turnaround : 

This  is  dependent  upon  the  computer  system  to  be  used.  A ' 
general  estimate  is  on  the  order  of  one  to  several  minutes 
for  the  time  required  to  run  a job  for  a complete  weather 
year,  on  a Uni vac  1108  Exec  8 System. 

8.  Documentation : 

Detailed  Users  Manual  is  available  from  owners  [ 2 1 ] . 


Scope : 

The  ESOP  provides  for  analysis  of  energy  reclamation  systems 
only  i.e.,  the  use  or  recycling  of  process  material  products 
such  as  solid  waste  is  not  included  in  the  simulation.  ESOP 
predicts  hourly,  daily,  monthly,  seasonal,  and  yearly 
operational  characteristics  for  any  or  all  of  thirty  dif- 
ferent MIUS  configurations. 

ESOP  has  the  capability  of  analyzing  two  types  of  MIUS;  a diesel/ 
turbine  prime  mover  system  and  a steam  power  plant  (boiler) 
prime  mover  system.  The  selection  of  system  type  analysis 
is  a user  option.  Bol^  systems  use  the  same  solid 


waste  disposal  system  options. 


10.  Output : 

The  output  from  ESOP  is  fixed  and  in  sufficient  detail  to 
allow  for  analyses  and  comparisons  as  required.  Output 
categories  include: 

a.  An  echo  of  input  data. 

b.  Recovered  heat  and  operating  dollar  values  for 
waste  processing. 

c.  Daily  profiles  for  hot  water,  space  heating, 
and  space  cooling  demand. 

d.  Fuel  requirements  and  cost  for  conventional  system 
(seasonal  and  yearly) . 

e.  Fuel  requirements  for  MIUS  option  considered 
(seasonal  and  yearly) . 

f.  Hourly  thermal  storage,  if  applicable 

11.  Input : 

Input  is  straightforward  and  logical.  There  are  approximately 
100  parameters  of  which  some  24  are  required  for  input.  The 
namelist  option,  defined  under  FORTRAN  V,  is  used  to  input 

all  data  to  ESOP.  Five  namelists  are  required  input  for 
each  data  case.  Descriptions  of  these  five  namelists 
follow: 


a.  WASTE  - Namelist  WASTE  contains  input  variables  which 
define  the  amount  of  waste  to  be  disposed  of,  the 
waste,  heating  value,  the  quality  of  the  waste,  the 
cost  of  the  required  fuel,  capacity  of  the  incinerator 
unit,  the  total  quantity  of  recovered  waste,  and 

the  waste  heat  usage  profile. 

b.  PYRINC  - Namelist  PYRINC  contains  input  variables 
which  define  the  operating  characteristics  of  the 
pyrolysis  process  and  heat  recovery  efficiencies 
of  both  the  incineration  and  pyrolysis  processes. 

c*  INPUT  - Namelist  INPUT  contains  variables  which 

define  the  construction  of  the  building  to  be  analyzed, 
the  number  of  buildings,  number  of  .apartments  in  each 
building,  the  hot  water  heating  demand  per  building, 
and  a cloud  factor  which  is  not  used  in  the  analysis 
at  present. 

d.  ENVRHR  - Namelist  ENVRHR  contains  input  variables 

which  define  twenty-four  hour  profiles  of;  inside  and 
outside  dry  bulb  temperatures  and  air  enthalpies, 
domestic  and  auxiliary  electric  demands,  occupancy, 
hot  water  usage,  apartment  ventilation  rates,  window 
shade  factor,  direct  solar  radiation  through  windows, 
window  heat  gain  (convection  and  radiation)  , and 
"equivalent,  temperature  differentials"  for  the  building 
roof  and  walls. 
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e.  CONST  - Namelist  CONST  contains  input  variables  which 
define  diesel  and  turbine  rated  loads,  a generator 
rated  load  (for  the  Waukesha  500  KW  diesel  system) , 
boiler  efficiencies  (for  both  24  and  12  mode  systems), 
coefficients  of  performance  for  air  conditioning 
systems,  percentage  absorption/compression  for  the 
fixed  ratio  mode,  boiler  operating  characteristics 
(for  the  steam  power  plant) , program  logic  flags 
for  season,  prime  mover  system,  and  low  grade  heat 
utilization  selection,  low  grade  heat  recovery  and 
usage  characteristics,  and  water  cooling  tower 
operating  characteristics. 

12.  Logical  Structure: 

ESOP  consists  of  5 general  analytical  components  covering 
waste  disposal,  heating/cooling  loads  determination,  power 
generation  and  a conventional  utility  system,  plus  other 
processing/interpolativetype  subroutines.  The  overall 
structure  of  ESOP  is  shown  in  Figure  3.  The  five  major 
components  are: 

a.  Solid  Waste  Disposal  Subroutine  (SWDP) : 

SWDP  calculates  operating  parameters  and  daily  total 
energy  input  required  for  three  types  of  solid  waste 
disposal  systems;  incineration,  pyrolysis,  and 
combination  incineration/pyrolysis . Process  byproducts 
and  recoverable  waste  energy  are  also  calculated. 

b.  Generator  Subroutine  (GENRAT) : 

GENRAT  calculates  the  hourly  energy  requirements  for 
specific  prime  mover/generator  units  as  a function  of 
input  electrical  load  demands.  It  also  computes 
the  hourly  rate  of  waste  heat  energy  that  is  recovered 
or  recoverable  from  prime  mover  heat  exchanger  systems. 

c.  HEAIR : 

HEAIR  calculates  the  heating  and  cooling  loads  on  a 
specific  building  with  given  internal  and  external 
environmental  conditions  for  each  hour  of  a 24-hour 
day . 

d.  CONVEN: 

This  subroutine  calculates  the  hourly  energy  require- 
ments for  a conventional  utility  power 
system  to  meet  the  total  system  load  demands.  The 
configuration  is  composed  of  a boiler  system  identical 
to  MIUS  and  a commercial  electrical  power  generating 
source  operating  at  a constant  30%  efficiency  level 
for  delivered  power.  Only  compression  type  air  cond- 
itioning is  utilized  and  no  waste  heat  energy  is 
utilized  or  recovered.  Daily,  monthly,  and  seasonal 
energy  requirements  are  calculated  for  comparison  with 
MIUS  energy  requirements. 
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e.  STEAM: 

This  subroutine  calculates  the  energy  requirements  and 
operational  characteristics  of  a MlUS-type  steam  power 
plant.  Four  configurations  are  available  as  options. 


13.  Flexibility: 

The  ESOP  will  operate  with  a minimal  number  of  input  terms 
being  specified,  thus  sufficing  for  a preliminary  design. 

On  the  other  hand,  it  will  accommodate  quite  detailed  input 
information  to  suffice  as  a more  thorough  design  tool.  The 
number  of  configurations  simulated  through  various  combinations 
of  individual  equipment  simulations  are  24  for  diesel/turbine 
prime  mover  MIUS  designs,  12  for  steam  power  plant  MIUS 
designs,  and  one  conventional  utility  delivery  design 
(described  above  under  12d) . Detailed  lists  of  all  these 
configurations  are  presented  in  the  ESOP  user’s  manual  [21]. 

14.  Interfacing: 

The  ESOP  is  an  "open"  program  and  is  written  in  such  a manner 
as  to  easily  allow  modification  of  either  input  to  or  output 
from  it  to  accommodate  an  interfacing  with  many  other  type 
programs  as  desired. 

15.  Limitations : 

There  are  presently  hardware/equipment  simulation  limitations 
in  the  ESOP,  however,  the  capabilities  can  be  easily  expanded. 
Comparisons  can  be  made  only  on  an  energy  consumption  basis 
and  not  on  a dollar  basis  since  there  are  no  economic  criteria 
considered  in  ESOP.  Separate  parts  do  not  operate  independ- 
ently, and  no  midstream  evaluation  is  possible.  There  are 
no  building  air-side  simulations,  and  there  is  not  a capability 
to  account  for  simultaneous  heating  and  cooling  loads.  Only 
four  24-hour  weather  days  are  analyzed  (one  for  each  season) 
instead  of  the  365  days  accomplished  for  a true  hourly 
.calculation  for  loads. 

16.  Source  Language: 

The  source  language  of  ESOP  is  Fortran  V. 

17.  Hardware  Implementation: 

It  has  been  implemented  on  Univac  equipment  under  both 
EXEC  II  and  EXEC  VIII. 

18.  Portability : 

ESOP  is  hardware  independent,  within  the  limitations  of 
Fortran  compiler  variability. 

19 . Diagnostics : 

There  are  no  printed  diagnostics  as  such.  Standard  UNIVAC 
systems  diagnostics  are  available,  but  printing  is  suppressed 

in  ordinary  use. 
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20.  Maintenance : 

Maintenance  of  ESOP  will  be  handled  by  the  authors. 


21.  Adaptability/Expandability : 

ESOP  can  be  readily  changed  or  adapted  to  virtually  any 
operation  desired. 

22.  Evaluative  Summary: 

The  NASA  ESOP  program  system  is  one  of  four  programs 
described  in  this  report  which  was  specifically  developed 
to  simulate  the  energy  performance  of  typical  MIUS  configurations, 
and  to  compare  that  performance  with  a conventional  utility 
system  satisfying  the  same  loads.  At  this  time,  no  comparative 
economic  analysis  is  available  as  part  of  the  system.  The 
various  subprograms  calculate  building  loads  and  subsequently 
accomplish,  a steady-state  energy  requirements  simulation 
of  several  MIUS  configurations  and  a conventional  one. 

Building  thermal  load  calculations  are  based  on  1965  ASHRAE 
recommended  procedures  [22]  and  utilize  Trane  solar  data  [23]. 

This  method  is  based  on  finding  a hypothetical  "equivalent 
temperature  difference"  which  yields  a calculated  fictitious 
transmission  thermal  load  which  is  equal  to  the  real  thermal 
load  due  to  all  the  various  possible  sources  of  effects: 
transmission,  radiation,  solar  loading,  building  heat  storage, 
ventilation,  etc.  Subsequent  ASHRAE  recommendations  [L8  ] 
have  largely  superseded  this  method.  Base  and  auxiliary 
loads,  including  thermal  requirements  for  hot  water  heating, 
are  calculated  from  input  schedules.  A shortcoming  of  these 
schedules  is  their  lack  of  ability  to  account  for  variations 
in  occupancy  and  activity  patterns  caused  by  weekends  and 
holidays.  The  schedules  are  assumed  to  be  the  same  for  all 
days  of  the  year.  The  loads  calculated  are  on  an  hour-by-hour 
basis.  However,  this  is  only  done  for  four  24-hour  weather 
profiles  representing  seasonal  average  characteristics.  The 
subsequent  loads  obtained  from  these  four  seasonal  days, 
are  then  multiplied  by  monthly  and  seasonal  time  durations  to 
get  related  energy  consumptions  for  those  time  periods. 

Thus,  the  calculation  is  not  truly  and  hour-by-hour  analysis 
for  the  whole  year.  In  fact,  it  makes  little  sense  to  calculate 
a monthly  energy  consumption  based  on  the  properties  of  a 
seasonally  average  day.  In  addition,  because  of  the  lack  of 
energy  performance  simulations  for  air-side  systems,  the 
program  cannot  account  for  the  existence  of  simultaneous 
heating  and  cooling  loads.  This  limits  program  analysis 
capability  mostly  to  hypotheical  building  project  configurations, 
since  it  cannot  model  the  many  existing  building  types  that  do 
present  simultaneous  loads.  All  these  considerations  suggest 
that  the  loads  produced  by  this  program  are  limited  in  suit- 
ability to  comparative  analyses  of  the  plant  systems  designed 
to  satisfy  the  loads,  and  not  actual,  realistic  predictions 
of  actual  p„er formance.  It  should  be  noted  that  a recognition 
of  this  limitation  by  the  developers  of  the  program  system 
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is  implicit  in  the  title  chosen:  "Energy  Systems  Optimization 
Program." 

The  energy  requirements  simulations  include  a total  of  thirty 
six  variations  of  possible  MIUS  configurations  which  differ 
as  to  the  combinations  of  the  various  individual  thermal 
processes:  solid  waste  processing,  power  generation,  and 
energy  supply  for  heating  and  cooling.  All  simulations  are 
of  the  steady  state,  energy  balance  type,  and  are  done  on 
the  same  hourly  basis  as  the  load  calculations.  There  is  a 
mix  of  both  fixed  conversion  efficiencies  in  some  processes, 
and  part-load  performance  curves  in  others  (e.g.  power  generation). 
In  particular,  it  is  possible  to  input  an  hour-by-hour  COP 
profile  for  a chiller  system,  but  since  chiller  COP  usually 
correlates  with  the  amount  of  the  load,  it  is  not  clear  what 
the  hourly  profile  flexibility  accomplishes.  There  is  a 
pyrolysis  simulation  available  in  this  program,  a feature 
available  nowhere  else  at  this  time.  It  is  not  clear,  however, 
whether  the  assumption  that  byproduct  gas  created  by  this 
process  should  be  sold  for  an  operating  dollar  credit  takes  the 
best  advantage  of  the  integration  possibilities  of  such  a 
subsystem  into  a total  MIUS  configuration.  In  particular  the 
possibility  of  recycling  this  gas  as  a MIUS  fuel  for  an  energy 
"credit"  should  be  examined.  The  power  generation  subroutine 
simulates  the  performance  characteristics  of  six  prime-movers 
alternatives,  four  of  which  are  diesel  engines,  and  two  of  which 
are  turbines.  It  should  be  noted  that  of  the  four  diesel 
performance  simulations,  two  of  them  are  for  models  produced 
by  a company  which  has  now  ceased  operations  (Nordberg) . The 
resultant  overall  nature  of  the  simulation  available  indicates 
that  this  program  system  is  best  suited  for  conceptual  level 
estimates  of  comparative  energy  feasibility  of  the  various 
configurations  simulated  for  a particular  set  of  site  loads, 
both  with  respect  to  alternative  MIUS  configurations,  and  with 
respect  to  the  one  conventional  configuration  which  is  simulated. 
This  program,  in  its  present  form,  could  not  be  expected  to 
accurately  predict,  on  a reliably  consistent  basis  the  actual 
energy  performance  of  many  real  systems,  due  to  the  limitations 
discussed  above. 
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3,13  MIUS  SINDA  Models 


1.  Abstract : 

Two  MIUS  simulation  models  have  been  developed  for  operation 
on  the  Systems  Improved  Numerical  Differencing  Analyzer 
(SINDA)  program.  SINDA  is  a program  capable  of  performing 
transient  or  steady-state  analyses  on  any  system  which  may 
be  represented  in  lumped  parameter  fashion  (nodalized)  and 
whose  operation  is  governed  by  diffusion  equations.  The 
program  was  initially  designed  for  thermal  analysis  of 
spacecraft  structures,  but  is  not  limited  to  that  field. 

One  of  the  two  MIUS  models  developed  for  operation  on  the 
SINDA  program  describes  a MIUS  equipment  configuration 
which  was  designed  for  the  648-unit  garden  apartment  trade 
study.  The  second  was  developed  to  simulate  the  MIUS  In- 
tegration and  Subsystems  Test  (MIST)  hardware  configuration, 
which  is  at  NASA-Johnson  Space  Center,  Houston,  Texas. 

2 . Author(s) : 

a.  SINDA  Program:  TRW  Systems,  Inc.,  and  NASA  Johnson 

Space  Center  (JSC),  Structures  and  Mechanics 
Division. 

b.  MIUS  SINDA  Models:  TRW  Systems,  Inc.,  The  Boeing 

Company,  and  NASA,  JSC,  Urban  Systems  Project 
Office  (USPO). 

3.  Owner (s) : 

a.  SINDA:  Public  (U.S.  Government) 

b.  MIUS  SINDA  Models:  Public  (U.S.  Government) 

4 . Availability : 

a.  SINDA  - available  through  R.  L.  Dotts  at  NASA-JSC. 

b.  MIUS  Models  - available  through  USPO. 

5 . Cost : 

Operation  cost  is  very  model  dependent  and  is  a function 
of  the  type  of  analysis  (steady-state,  transient,  etc.), 
time  steps  required  to  force  mathematical  stability  because 
of  physical  properties  of  MIUS  components,  etc.  The 
cost  of  performing  specific  analyses  with  the  program  is 
largely  dependent  upon  the  extent  of  modifications  required 
for  the  particular  MIUS  configuration  to  be  considered. 

Minor  modifications  can  be  accomplished  quite  readily  in 
approximately  one  man-week. 

Typical  execution  times  for  the  current  model  configuration 
on  the  Univac  1110  Exec  VIII  system  at  JSC  are  less  than  one 
minute  per  day  of  real-time  plus  approximately  two  minutes 
for  editing  and  compliation.  Costs  would  be  dependent  on 
the  particular  computation  center  where  the  system  is  implemented. 
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6. 


Human  Factors; 

Preparation  of  input  data  and  changes  to  the  model  are  fairly 
easy  if  the  user  is  familiar  with  the  SINDA  program  and 
Fortran.  Output  is  completely  flexible  and  is  controlled 
by  the  user  either  through  the  use  of  SINDA  output  subroutines 
or  user-written  output  formats. 

The  MIUS  model  is  not  easy  to  use  and  modify  due  to  its 
complexity  and  flexibility.  However,  a familiarization 
with  the  SINDA  program  and  Fortran  will  enable  the  user  to 
tailor  the  program  to  a wide  vareity  of  applications. 

7.  Turnaround : 

Turnaround  at  the  JSC  computing  facility  varies  from 
approximately  2-3  hours  to  2-3  days  depending  primarily  on 
availability  of  hardware,  when  processing  is  done  in  batch 
mode. 

8 . Documentation : 

The  SINDA  program  has  been  documented  with  a user's  manual 
[24j,  and  an  engineering  program  manual  [25]  which  have 
been  published  and  are  available. 


9.  Scope : 

One  current  MIUS  model  was  developed  specifically  to  simulate 
a 648-unit  garden  apartment  MIUS.  This  model  currently  predict 
flow  rates  and  temperatures  throughout  the  system,  and  from 
those  predictions  derives  fuel  consumption,  energy  losses, 
equipment  operation  schedules,  etc.  The  second  model  simulates 
the  behavior  of  similar  physical  parameters  for  the  MIST  hard- 
ware model,  which  is  constructed  at  NASA-USPO.  The  models  are 
truly  applicable  only  to  the  particular  MIUS  configurations 
simulated;  however,  modifications  will  allow  analysis  of  a 
fairly  wide  variety  of  MIUS  configurations  and/or  control 
techniques . 

10.  Output : 

For  both  models  the  user  has  complete  control  over  all  output 
through  the  use  of  either  standard  SINDA  output  routines  or 
through  his  own  Fortran  statements.  Any  or  all  output  is 
available  at  any  time  during  the  solution  or  at  any  time 
interval.  The  models  output  all  temperatures  and  flow  rates 
as  well  as  several  parameters  which  define  the  particular 
system  operation  at  hourly  intervals.  Also  available  are 
seasonal  and  yearly  totals  of  several  system  parameters  such 
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as  fuel  consumption. 

Due  to  the  detailed  nature  of  the  models,  the  output  is  currently 
quite  lengthy  and  requires  a familiarity  with  the  models  and 
their  nodalization  for  meaningful  interpretation. 

11.  Input : 

The  current  MIUS  models  are  retained  on  magnetic  tape  at  the 
JSC  computer  facility.  Thus,  to  execute  them,  the  only  input 
required  is  an  appropriate  set  of  system  control  cards  and 
SINDA  control  cards  necessary  to  load  and  compile  and  appropriate 
model  from  tape.  Parameters  such  as  load  profiles,  equipment 
performance  curves,  temperature  profiles,  etc.,  may  be  input 
as  required  by  modifying  the  stored  data  through  standard 
editing  procedures.  Input  to  the  SINDA  program  to  define  each 
complete  model  includes  a description  of  all  nodes  and  conductors 
(for  the  RC  network  system  simulation  procedure) , thermal 
sources,  solution  sequence  and  technique  desired,  and  special 
purpose  user-supplied  subroutines  required,  and  output  logic 
desired . 

The  garden  apartment  model  will  accept  magnetic  tape  input  of 
building  loads  from  the  Post  Office  program. 

12 . Logical  Structure: 

The  SINDA  program  is  composed  on  three  primary  sections: 

(a)  A preprocessor  which  compiles,  sorts,  and  stores  all 
input  data,  user  supplied  logic,  and  order  of  solution. 

(b)  Standard  solution  routines  which  are  called  upon  to 
solve  the  network  constructed  by  the  preprocessor. 

(c)  A large  library  of  optional  subroutines  which  are 
available  to  perform  a wide  variety  of  special  purpose 
functions  input/output  control,  mathematical  manipulations, 
etc . 

Both  of  the  MIUS  models  have  been  developed  as  an  application 
of  the  SINDA  logical  structure. 

13.  Flexibility : 

The  SINDA  program  is  extremely  flexible  for  analysis  of  any 
system  which  can  be  represented  by  a lumped  parameter  (nodal) 
network  governed  by  diffusion  equations.  The  existing  SINDA 
subroutine  library  is  quite  comprehensive  and  can  be  supplemented 
with  user-supplied  subroutines. 

The  current  MIUS  models  are  also  somewhat  flexible,  as  long  as 
major  changes  from  the  programmed  physical  configurations  are 
not  required.  A wide  variety  of  MIUS  analyses  may  be  readily 
performed  with  only  minor  variations  in  the  model. 
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Ultimate  flexibility  is  limited  only  by  resources  available 
for  new  model  development  within  the  framework  of  the  SINDA 
system  and  computer  hardware  limitations. 

14.  Interfacing: 

Numerous  interfaces  between  SINDA  and  other  software  systems 
have  been  accomplished,  and  the  extent  of  required  modifications 
is  a function  of  the  particular  application.  The  MIUS  garden 
apartment  model  has  been  interfaced  with  the  Post  Office  program 
to  provide  automated  input  of  MIUS  thermal  loads. 

15.  Limitations : 

The  limitations  of  the  SINDA  program  for  MIUS  modelling  is 
dependent  primarily  upon  the  abilities  of  the  user  and  the 
resources  available  for  model  development.  The  effort  required 
to  accomplish  major  modifications  in  the  model  makes  detailed 
analyses  of  different  physical  configurations  impractical  in 
short  periods  of  time.  Another  limitation  in  the  use  of  the 
SINDA  program  is  the  degree  of  familiarity  with  SINDA  required 
for  effective  use  of  the  program. 

The  limitations  of  the  existing  MIUS  models  include  largely 
those  of  the  SINDA  program.  The  existing  models  include 
representations  of  diesel  and  gas  turbine-driven  generators, 
absorption  and  compression  chillers,  boilers,  incinerators, 
distribution  piping,  heat  exchangers,  and  rairly  extensive 
control  logic.  Currently,  the  models  contain  only  thermal 
networks  integrated  with  fluid  flow.  No  pressure  networks 
are  included.  The  HVAC  loads  are  assumed  to  be  concentrated 
at  one  central  heat  exchanger  rather  than  from  individual 
sources.  No  air  side  simulation  is  included.  Simulation  of 
waste  water  treatment  equipment  is  limited  to  the  EPA  sewage 
plant  design  program  and  is  not  integrated  with  the  remaining 
MIUS  equipment.  Currently,  no  heat  storage  equipment  is 
simulated.  The  items  listed  can  be  added  to  the  model  with 
a relatively  minor  effort  in  most  cases. 

16 . Source.  Language: 

The  SINDA  source  language  is  primarily  Fortran  V,  although 
a small  amount  of  SLEUTH  machine  language  is  used,  which  is 
machine  dependent. 

17.  Hardware  Implementation: 

The  MIUS  model  is  operational  on  JSC's  Univac  1108,  1106,  and 
1110  under  Exec  II  and  Exec  VIII  monitor  systems.  SINDA  is 
also  operational  on  CDC  6600,  IBM  360/370  and  others. 

18.  Portability: 

SINDA  is  fairly  hardware  dependent  and  often  requires  a 
relatively  large  effort  to  change  environments.  However, 
several  versions  of  the  program  are  available,  and  once  it 
is  operational  in  a given  environment,  only  minor  modifications, 
if  any  should  be  required  to  operate  the  MIUS  models. 
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19.  Diagnostics : 

SINDA  diagnostics  and  modeling  aids  are  quite  good.  A few 
special  diagnostics  have  been  added  through  user  input  for 
the  MIUS  models. 

20.  Maintenance : 

SINDA  - Robert  L.  Dotts,  Johnson  Space  Center 
MIUS  models  - Urban  Systems  Project.  Office,  Johnson 
Space  Center 

21.  Adaptability /Expandability: 

Changes  to  the  SINDA  program  usually  require  a very  thorough 
knowledge  of  the  program  and  a fairly  large  effort.  Special 
purpose  subroutines  can  be  easily  formatted  for  standard 
SINDA  calling  sequences  and  added  to  a special  source  tape. 
Variations  on  the  MIUS  models  could  be  greatly  expanded  within 
the  SINDA  framework  and  are  limited  only  by  familiarity  with 
SINDA  and  computer  hardware  limitations.  The  current  models 
can  be  expanded  considerably  with  no  hardware  problems  on  the 
JSC  Univac  1110  Exec  VIII  system. 

22.  Evaluative  Summary: 

The  application  of  the  SINDA  program  to  the  two  model  simu- 
lations discussed  in  this  section  constitute  the  only  programs 
developed  for  MIUS  simulations  which  have  the  capability  of 
accomplishing  true  transient  simulations  of  the  various  energy 
conversion  processes.  To  date,  however,  only  steady-state 
simulations  have  been  performed,  and  the  transient  simulation 
capabilities  have  not  been  utilized.  Compared  to  other 
programs  discussed  in  this  report,  the  SINDA  models  require 
a greater  amount  of  effort  to  accomplish  a simulation.  In 
addition,  although  SINDA  is  very  flexible  itself,  each  of  the 
actual  simulation  models  developed  are  fixed  in  configuration. 
Any  change  in  a model  involves  actual  changes  to  the  software 
itself;  it  is  not  possible  under  user  control  by  simple  changes 
of  input  data  cards.  In  a sense,  in  fact,  most  of  the  input 
for  a simulation  is  built  in  to  the  program  itself.  This 
difficulty  of  input  also  leads  to  an  increased  possibility 
of  error,  an  example  of  which  is  examined  in  a discussion 
of  the  ESOP/MIUS  SINDA  garden  apartment  simulation  in  the  next 
section.  In  view  of  the  fact  that  the  amount  of  effort  involved 
in  developing  an  operational  simulation  model  with  SINDA  is 
so  much  greater  than  for  the  other  programs  discussed  in  this 
report,  and  because  of  the  effort  involved  in  modifying 
simulations,  it  is  being  misapplied  in  performing  steady-state 
analyses,  and  should  be  used  only  when  the  transient  analysis 
capabilities  are  utilized.  It  is  hoped  that,  particularly  in 
the  case  of  the  MIUS  SINDA  model,  the  transient  analysis 
capability  will  be  employed. 
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In  that  application,  it  will  probably  be  of  benefit  in 
systematically  examining  transient  behavior,  and  should  be 
able  to  indicate  methods  of  optimizing  overall  performance 
through  proper  design  of  control  processes.  It  is  in  areas 
such  as  this,  where  the  unique  transient  simulation  capabilities 
of  this  system  can  be  utilized,  that  use  and  further  development 
of  simulation  models  based  on  SINDA  are  justified. 
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1*.  Program  Comparison  Activities 
Many  others  have  previously  recognized  the  need  for  validation 
of  program  predictions,  with  respect  to  actual  performance,  and  for 
inter comparison  with  each  other.  A number  of  program  comparison 
activities  have  been  carried  out,  four  of  which  are  described  below, 
along  with  comments  regarding  the  pertinence  of  their  findings  to  the 
MIUS  effort. 

A.  Boeing- Lockheed  MIUS  Simulation  Program  Correlation  (SINDA/ESOP) 

In  a supporting  effort  to  NASA-USPO,  the  Boeing  Corporation 
compared  the  calculated  annual  electrical  and  fuel  energy  require- 
ments using  the  SINDA  and  ESOP  programs  for  an  early  version  of 
the  NASA  6U8-unit  garden  apartment  configuration  using  typical 
weather  conditions  for  Houston,  Texas  and  Seattle,  Washington. 

In  both  cases,  the  operation  logic  of  the  MIUS  system  consisted  of 
generating  the  required  electrical  power  and  utilizing  the  waste 
heat  in  the  most  efficient  manner  to  satisfy  the  hot  water  and 
domestic  heating  and  cooling  demands.  The  ESOP  and  SINDA  simulations 
are  different  in  both  the  simulation  models  and  in  calculational 
logic,  leading  to  different  and  non-comparable  methods  of  describing 
component  and  subsystem  interfaces  and  operational  interactions  in 
each  of  the  programs.  Thus  the  only  two  calculated  parameters  that 
could  be  directly  compared  were  the  annual  electrical  power  and 
fuel  consumptions  for  the  modelled  configuration.  Results  showed 
annual  electrical  and  fuel  consumption  agreements  of  about  3 % and 
5 I respectively  for  Houston  and  about  1%  and  5%  respectively  for 


Seattle . 
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B.  ESOP/Meriwet her /E-CUBE 

NASA  USPO  has  also  accomplished  a comparison  of  their  inter- 
nally developed  ESOP  program  and  the  commercially  available 
services  of  the  E-CUBE  and  Meriwether  programs.  This  comparison 
was  limited  to  predicted  heating  and  cooling  energy  requirements  for 
the  Park  Towers  South  Office  Building  model  used  in  the  NASA-USPO 
Office  Building  Trade  Study.  The  weather  data  used  was  based  on 
four  typical  seasonal  days  for  Houston,  Texas  which  was  input 
directly  to  ESOP.  The  seasonal  days  were  modified  to  simulate  the 
full  year  of  weather  data  necessary  for  E-CUBE  and  Meriweater 
analyses.  An  important  variable  was  cloud  cover,  which  ranged  from 
none  to  "full",  and  was  handled  differently  by  each  program. 
Variations  in  the  predicted  heating  energy  requirements  between  the 
other  two  programs,  with  ESOP  results  as  a reference,  ranged  from 
22%  lower  to  l6%  higher  depending  on  the  cloud  cover  parameter. 

The  analagous  variations  in  the  cooling  energy  requirements  ranged 
from  7 l lower  to  bOl  higher  than  the  ESOP  results  as  a reference 
base.  A comparison  of  electricity  and  fuel  requirements  was  not  made 
due  to  ESOP  program  limitations.  Since  no  actual  building  energy 
consumption  data  was  available,  it  was  not  possible  to  determine 
which  of  the  programs  would  have  made  the  best  actual  prediction 
of  enegy  performance.  The  activity  was  therefore  a comparative  one, 
based  on  examining  consistency  of  results  for  the  different  programs. 
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C.  ASHRAE  "Project  Crosscheck" 

In  1967  ASHRAE  established  a task  group  to  investigate  and 
propose  improved  methods  for  estimating  the  energy  requirements  for 
heating  and  cooling  buildings.  This  task  group  decided  that  it 
would  be  beneficial  to  compare  several  computer-based  algorithms 
that  had  been  developed.  In  what  was  to  become  the  first  phase  of 
"Project  Crosscheck",  five  different  programs  attempted  to  predict 
the  heating  and  cooling  loads  of  a hypothetical  20  story  building 
assuming  five  independent  zones.  The  five  participants  were: 

1.  Alabama  Power  Company 

2.  American  Electric  Power  Service  Corporation 

3.  Ross  F.  Meriwether  and  Associates,  Inc. 

4.  Texas  Electric  Service  Corporation 

5.  Westinghouse  Electric  Company,  Inc. 

Plots  of  the  results  showed  that  all  five  participants  found 
essentially  the  same  variations  in  loads  with  weather  conditions, 
e.g.  the  magnitude  of  the  worst  case  exterior  zone  monthly  heating 
and  cooling  loads  were  within  a bandwidth  of  19 l and  1 h% , about 
the  means  respectively.  These  bandwidths  were  both  on  the  south 
face  indicating  differences  in  the  treatment  of  solar  load.  The 
maximum  differentiation  of  + 100%  from  the  mean  occurred  in  the 
core  zone  of  the  building. 

The  ASHRAE  Task  Group  was  later  given  formal  standing  as 
Technical  Committee  1.5  on  Computer  Applications.  This  committee 
realized  a need  not  only  for  the  evaluation  of  precision,  as 
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shown  in  Phase  I,  hut  also  for  an  evaluation  of  program  accuracy. 
Under  funding  from  the  National  Science  Foundation,  Ohio  State 
University  (OSU)  had  instrumented  the  Law  Center  on  the  OSU  campus 
in  Columbus,  Ohio.  The  data  obtained  included  heating  and  cooling 
power  requirements  (not  loads)  and  weather  data  in  addition  to  an 
extremely  accurate  model  of  the  building  system.  The  committee 
decided  to  compare  the  various  current  computer  programs  using 
Columbus , Ohio  weather  data  to  the  OSU  model  using  the  same  weather 
data  [26  ].  The  following  participants  are  involved  in  Phase  II: 

1.  Ross  Meriwether  and  Associates  (represented  by  the  Dept. 

of  Public  Works,  Canada) 

2.  Electric  Energy  Association 

3.  Texas  Electric  Service 

American  Electric  Power  Service  Corporation 
The  result  of  this  effort  is  described  in  [27  ]. 

D.  NBSLD/E-CUBE  Omaha  High-Rise  Comparison 

At  the  request  of  HUD,  an  analysis  of  building  energy  (natural 
gas  and  electricity)  consumption  for  a selected  typical  weather 
year  was  conducted  by  NBS  on  Kay-Jay  Towers,  a 12  story,  118-unit 
apartment  building  in  Omaha,  Nebraska,  using  the  computer  program 
NBSLD  and  a simple  building  system  simulation  program  developed 
for  this  particular  building  [28].  The  purpose  of  this  effort  was 
to  compare  the  NBSLD  results  both  with  similar  results  calculated 
by  the  Northern  Natural  Gas  Company  using  the  E-CUBE  program  and 
with  actual  metered  5-year  average  energy  consumption  data  which 
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was  available.  Both  programs  used  the  same  zone  configurations  in 
the  thermal  modelling  of  the  building  and  simulated  the  same  mech- 
anical and  air  handling  aspects  of  the  building  plant.  Both  employ- 
ed actual  equipment  and  building  operating  schedules  and  indoor 
environmental  conditions.  While  NBSLD  accounted  explicitly  for 
the  effects  of  air  infiltration  on  space  thermal  loads,  the  data 
input  to  E-CUBE  did  not. 

Although  there  were  wide  monthly  discrepancies  in  energy  use  pre- 
dictions by  both  programs  compared  to  the  metered  data,  the  annual 
consumption  totals  for  both  programs  nevertheless  agreed  with  the 
actual  use  to  within  one  percent  for  natural  gas  and  a few  percent 
for  electricity.  It  is  unclear  at  the  present  time  how  these  re-* 
suits  are  to  be  interpreted,  but  they  do  raise  the  important 
question  of  how  E-CUBE  came  so  close  to  the  actual  consumption 
while  neglecting  the  large  effects  of  air  infiltration  throughout 
the  analysis  year. 

None  of  the  above  activities  has  produced  a comprehensive 
validation  or  comparison  of  energy  analysis  computer  programs.  The 
most  notable  reason  for  their  failure  was  the  use  of  incorrect  comparison 
methodologies.  They  were  all  "one-point"  comparisons,  in  the  sense  that 
a given  applicational  ("site")  situation  was  picked,  which  in  turn 
determined  the  utility  loads  to  be  satisfied,  and  the  system  energy 
performance  was  then  calculated  by  the  different  computer  programs 
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involved  in  the  comparison.  The  results  were  then  examined  for  the 
quality  of  the  agreement  among  themselves.  There  are  two  shortcomings 
to  this  approach.  First,  unless  there  is  also  measured  performance 
data  available  for  a real  system  reacting  to  the  same  loads  (and  which 
the  computerized  systems  must  stimulate)  then  there  is  no  way  of  knowing 
whether  the  computer  predicted  results  are  in  fact  accurate  or  not. 

All  that  can  be  determined  is  how  well  the  results  of  the  different 
programs  agree  or  disagree  among  themselves.  Of  all  the  comparison 
activities  that  have  been  undertaken,  only  the  NBSLD/E-CUBE  comparison 
on  the  Omaha  building  also  had  actual  energy  consumption  data  available, 
and  the  orientation  of  that  whole  effort  was  to  examine  the  energy 
requirements  of  a particular  building,  not  a utility  supply  system. 

The  second  deficiency  with  this  "one-point"  test  methodology  is  an 
inability  to  provide  the  data  base  for  comparison  of  optional  energy 
systems.  A meaningful  comparative  test  among  programs  should  be  de- 
signed in  a way  that  determines  whether  or  not  the  programs  come  to  the 
same  relative  conclusions,  i.e.  that  they  agree  on  the  optimal  utility 
system  configuration  for  a given  set  of  loads.  To  accomplish  this,  a 
set  of  several  configurations  or  a continuous  variation  over  a range  of 
configurational  performance  parameters  need  to  be  simulated  by  each  of 
the  programs  being  compared.  In  response  to  a given  set  of  loads,  the 
performance  simulations  of  the  whole  set  of  configurations  should  then 
be  carried  out  by  the  participating  programs.  Finally,  the  results  should 
be  compared  to  see  whether  or  not  the  programs  all  predict  the  same 
relative  performance  (including  the  "optimized  configuration")  for  the 
range  of  configurations  simulated.  This  is  the  kind  of  interprogram 
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test  that  has  meaning  for  the  comparative  types  of  simulation  programs, 
not  the  single-point  comparison.  The  above  considerations  apply  to 
both  building  load  determinations  and  energy  systems  simulation. 

A more  recent  report  describing  a comparison  of  selected  programs 
on  several  building  types  is  presented  in  reference  [1].  This  study 
gives  a particularly  valuable  description  of  the  differences  in  user 
factors  for  the  programs  involved. 


5.  Conclusions  and  Recommendations 


During  the  course  of  this  study,  a clearer  definition  of  MIUS 
requirements  for  computer  program  capability  was  formed,  and  is  summar- 
ized in  this  section  of  the  report.  This  definition  was  the  result  of 
interaction  between  initial  software  utilization  plans  and  this  analysis 
of  the  actual  capabilities  of  available  software.  Six  areas  of  analysis 
which  require  the  use  of  computer  programs  are  identified  below. 
Conclusions  regarding  the  adequacy  of  programs  described  earlier  in 
this  report  and  recommendations  for  additional  development  are 
discussed  in  the  context  of  these  six  areas. 

A.  Equilibrium  Comparative  Analysis 

The  first  area  of  analysis  requiring  computer  assistance 
is  the  comparison  of  alternative  MIUS  and  conventional  plant 
configurations  with  respect  to  energy  performance  using 
simplified  steady-state  energy  balance  simulations.  This 
capability  is  necesaary  to  determine  the  optimal  plant  which 
will  satisfy  given  site  utility  loads.  This  capability  will  be 
used  throughout  additional  conceptual  studies,  demonstration 
evaluation,  and  as  the  core  of  a later  "MIUS  Optimizer". 

It  is  clear  that  the  NASA  ESOP  and  ORNL  1971  Comparative 
Energy  Analysis  programs,  which  include  simulations  of  likely 
MIUS  configurations,  are  the  most  applicable  existing  programs. 
Close  followers  are  the  commercial  AXCESS  program  and  the  TAGS/ 
AXCESS  hybrid.  Because  of  their  non-proprietarity , availability, 
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flexibility,  and  quality,  as  discussed  in  the  appropriate 
evaluative  summaries,  these  last  two  programs  have  the  greatest 
present  value  to  MIUS  of  the  commercial  programs  considered  in 
this  study.  All  of  the  programs  mentioned  here  are  flexible, 
and  do  not  have  the  limitations  inherent  in  proprietary  pro- 
grams. The  implementation  of  these  programs  on  participating 
agency  computers  would  make  them  cost-effective  as  research 
tools.  In  addition,  the  modular  structure  of  these  programs 
lends  them  especially  well  to  being  modified  in  response  to 
changing  or  increased  interest  in  the  future. 

It  is  possible  then  to  conclude  that  with  the  capability 
represented  by  the  various  programs  in  the  possession  of  the 
agencies,  and  the  level  of  simulation  detail  they  contain,  there 
exists  a comparative  energy  analysis  capability  suitable  for  the 
needs  of  the  MIUS  effort.  However,  implementation  of  AXCESS  and 
the  TACS/AXCESS  hybrid  on  a participating  agency  computer  is  yet 
to  be  accomplished.  It  is  recommended  that  implementation  of 
these  programs  be  pursued,  or  alternatively  that  a new  program 
be  developed  with  similar  or  better  capabilities.  In  addition, 
a multi-point  comparison  should  be  conducted  between  these  pro- 
grams to  determine  if  they  agree  on  relative  performance  of  the 
system  configurations  that  are  simulated.  The  test  should  be 
based  on  a "typical"  application  with  several  regional  weather 
data  sets  and  a set  of  loads  from  a probable  development  con- 
figuration, for  example,  the  NASA  Community  Study,  or  the  ORNL 
Live  Model  Study. 
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B.  Economics 


The  second  area  of  analysis  requiring  computer  assistance 
is  the  economic  comparison  of  alternative  MIUS  and  conventional 
plant  configurations.  This  requirement  parallels  that  of  the 
energy  feasibility  analysis  described  above.  Several  of  the 
complete  energy  analysis  program  series  studies  include  an 
economic  analysis  of  alternatives.  It  should  be  added  that 
while  the  economic  comparison  exists  as  a set  of  computational 
algorithms,  the  economic  data  base  necessary  to  do  actual 
comparisons  for  real  systems  at  this  time  appears  to  be  incom- 
plete and  not  in  a form  amenable  to  automatic  accessing  by 
a computerized  comparative  system. 

C.  Transient  Response 

The  third  need  for  computer  assistance  is  in  the  develop- 
ment of  more  sophisticated  transient  MIUS  simulation  models. 

These  are  needed  to  provide  improved  conceptual  optimization, 
accurate  plant  performance  predictions,  and  cost  effective 
control  schemes.  The  models  will  be  used  in  conjunction  with  MIUS 
demonstration  to  predict  and  validate  the  best  control  system 
methodologies . 
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While  the  present  level  of  detail  of  the  simulations  may  he 
adequate  for  comparative  performance  evaluations,  it  is  not 
possible  to  also  conclude,  however,  how  accurate  the  simulations 
are  in  the  prediction  of  the  actual  performance  of  a given  MIUS 
configuration.  At  this  time  there  is  no  data  to  conclusively 
confirm  or  deny  the  simulation  adequacy  under  these  circumstances. 
Greatly  simplifying  assumptions  are  inherent  in  the  equilibrium 
type  of  model.  Even  if  they  allow  for  thermal  capacities  in  the 
form  of  storage  and  losses  they  do  not  allow  for  the  actual 
effect  of  a real  control  system  on  the  time-response  of  the  MIUS 
to  time-varying  loads.  This  immediately  leads  one  to  consider 
such  a model  suspect  in  its  prediction  of  actual  performance, 
unless  it  is  proven  by  actual  testing  to  be  adequate.  What  is 
then  first  needed  is  a real  system  from  which  actual  performance 
can  be  measured,  and  which  can  also  be  modeled  on  the  computer. 

In  this  way  the  present  simulation  programs  can  have  their 
absolute  performance  predictions  compared  against  the  measured 
data.  Candidate  systems  for  this  comparison  activity  are  the 
NASA/MIST  facility  and  the  HUD  Jersey  City  Operation  BREAKTHROUGH 
instrumented  Total  Energy  plant.  If  a simulation  model  is  proven 
to  be  inadequate,  then  steps  should  be  taken  to  devise  those 
necessary  models  which  are  in  fact  adequate  for  an  actual  per- 
formance simulation.  Before  undertaking  the  major  development 
of  new  simulation  models,  the  alternative  benefits  to  be  derived 
from  generation  of  a reliable  performance  data  base  should  be 
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considered.  Any  simulation  is,  at  best,  as  accurate  as  the 
equipment  performance  data  it  utilizes.  If  the  present  data 
base  can  support  a higher  level  of  simulation,  and  this  addition- 
al level  of  complexity  is  necessary  to  adequately  predict  actual 
performance,  then  such  a development  should  be  initiated.  It  is 
felt  the  first  area  of  development,  with  the  greatest  immediate 
benefit  would  be  an  attempt  to  obtain  better  models  of  how  the 
control  systems  at  the  component,  subsystem  and  system  level 
actually  cause  a MIUS  configuration  to  respond  to  a particular 
time  dependent  utility  load  variation.  At  the  present  time, 
only  the  NASA  developed  SINDA  MIUS  models  have  the  potential 
for  this  type  of  analysis  in  the  public  domains. 

Building  Energy  Requirements 

The  fourth  area  of  analysis  requires  the  ability  to 
accurately  determine  building  thermal  loads  and  energy  requirement 
Valid  building  loads  and  energy  requirements  are  essential  for 
plant  optimization  and  accurate  prediction  of  site  energy  require- 
ments at  a particular  site.  A program  of  this  type  will  be  used 
to  translate  MIUS  site  characteristics  into  plant  requirements. 
Four  program  series  have  strong  capabilities  in  this  area,  and 
others  are  presently  under  development.  NBSLD,  through  probably 
the  most  accurate  and  flexible  building  load  calculation  program, 
and  in  fact  developed  as  a research  tool,  lacks  air-side 
mechanical  systems  and  equipment  simulation.  A final  comment  on 


the  relative  importance  of  loads  calculations,  air-side  systems 
simulations,  and  plant  equipment  simulations  is  in  order.  In 
any  program  series  which  has  all  of  these  capabilities , it 
is  probably  not  cost  effective  to  finance  development  of  new 
software  which  leads  to  a significantly  greater  level  of 
sophistication  in  any  one  of  these  areas.  The  need  for  loads 
calculation  and  air-side  system  simulation  capabilities  is 
adequately  satisfied  by  the  program  series  discussed  above. 

It  is  recommended  that  agency  participants  utilize  the  above 
program  series  in  calculation  of  site  energy  requirements. 


E.  Digital  Control 

The  fifth  area  of  analysis  requiring  computer  assistance 
is  the  development  of  the  actual  monitoring  and  control  algorithms 
for  digital  computer  control  of  a MIUS.  These  evolving 
algorithms  will  be  the  product  of  the  knowledge  gained  from  the 
simulation  programs  described  above,  and  from  operating  experience 
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at  early  demonstration  sites.  Although  no  existing  algorithms 
were  located  in  this  study.  Numerous  commercial  firms  and 
government  agencies  have  a demonstrated  capability  in  this  area. 
The  NASA  SINDA  MIST  model  has  the  potential  for  providing 
useful  information.  In  addition,  the  instrumented  Operation 
BREAKTHROUGH  Jersey  City,  MIUS  demonstration  will  provide 
valuable  experience  in  this  area. 

F.  Optimization 

The  ultimate  need  for  computer  assistance  is  in  pro- 
ducing a user-oriented  "MIUS  Optimizer".  This  program  will  be 
a commercial  tool  for  automatic  comparison  of  alternative  MIUS 
designs.  It  will  enable  MIUS  designers  to  select  the  best 
configuration  for  the  site  under  consideration.  The  purpose 
of  this  development  is  to  provide  increased  incentive  for 
commercial  implementation  of  the  MIUS  concept  by  making  it 
possible  to  easily  produce  good  designs.  The  next  section  out- 
lines current  developments  in  this  area. 

G.  Current  Developments  (1977) 

Two  programs  are  currently  being  developed  for  community- 
oriented  energy  analysis  which  will  have  significant  impact  on 
satisfying  needs  identified  in  areas  A,  B,  and  F as  outlined 
above.  Complete  descriptions  of  these  programs  are  not  avail- 
able at  this  time,  but  the  following  summaries  are  included  to 
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indicate  their  scope. 

1.  Analysis  of  Advanced  Coal-Using  Communities  (ACUCS) . 

The  overall  objective  of  the  ERDA-sponsored  ACUCS  program  is  the 
development  of  practical  alternative  systems  for  communities  use  that 
will  utilize  coal  in  a clean  and  efficient  way.  This  would  lessen 
the  dependence  of  the  community  on  oil  and  gas  and  facilitate  the 
utilization  of  traditionally  wasted  heat  to  satisfy  some  community 
energy  requirements.  Three  major  programmatic  activities  are  evalu- 
ation and  characterization  of  technologies  needed  for  coal-based 
systems,  collection  and  evaluation  of  community  load  data,  and  the 
development  of  computerized  system  design  methods. 

The  purpose  of  the  computer  model  will  be  to  provide  good  com- 
munity energy  system  designs  over  the  widest  possible  choice  of 
central  system  configurations  and  end-use  fuel  allocations.  The 
synthesis/optimization  program  is  designed  to  analyze  all  types  of 
technologies  and  to  consider  all  types  of  fuel-service  assignments. 

The  results  are  at  a generic  process  level  (e.g.  low  pressure  coal 
pyrolysis) . Consequently  the  program  is  expected  to  be  used  for 
preliminary  design  by  planners  and  design  engineers. 

The  design  program  will  be  a mathematical  optimization  model  that 
determines  the  minimum  cost  energy  system  (or  other  measure  of 
effectiveness)  that  satisfies  the  energy  needs  of  a community.  r*The 
program  requires  as  input  the  description  of  a set  of  generic  central 
conversion  processes  along  with  a physical  description  of  a community 
and  its  energy  needs  stated  as  service  demands,  i.e.,  BTU's  for 
heating,  cooling,  etc.  The  program  determines  the  following  (optimal) 


82 


system  configuration,  parameters,  and  operating  characteristics; 

° the  number  of  each  type  of  central  conversion 
device  to  install  in  the  community; 

° the  allocation  of  fuels  to  user  demands,  i.e., 
gas  for  heating,  electricity  for  cooling. 

These  allocations  can  he  different  for  different 
geographical  areas  and  different  economic  sectors. 

Thus  the  heating  in  an  area  near  the  central 
plant  may  he  provided  hy  thermal  heat  while  areas 
farther  from  the  central  plant  may  he  served  with 
gas  heating  systems; 

° the  number  and  type  of  storage  device  to  he  installed; 
° the  operating  levels  of  each  conversion  process 
and  storage  device  for  each  time  period  in  the 
year  being  modeled; 

° the  overall  system  efficiency; 

° individual  process  efficiencies; 

° initial  investment  costs,  yearly  maintenance  costs, 
and  yearly  fuel  costs; 

° related  system  measurements  such  as  land  area  re- 
quired, water  resources  required,  pollution  levels, 
etc . 
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Input  requirements  will  include,  but  not  be  limited  to  the 
following : 

0 General  community  characteristics  (e.g.,  available 
land,  zoning,  and  buildings) 

° Service  (e.g.,  space  heating)  and/or  energy  (e.g., 
electricity)  demands 
° Weather  profile 
° Time  horizon 
° Financial  limitations 
° Types  of  coal  available 
° Air  and  water  pollution  limits 
° Reliability  standards 

° Characteristics  of  existing  equipment 
° Limitations  on  equipment  to  be  considered 

Output  options  and  results  of  analysis  will  include: 

° Selection  of  generic  processes  for  fuel  conversion 
and  storage  at  central  and  secondary  sites  within 
the  community. 

° Identification  of  community  zones  and  fuel  types 
distributed  to  each. 

° Assignment  °f  fuels  to  end-use  service  demands  by 
community  zone  and  building  type. 
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2.  Advanced  Technology -Mix  Energy  System  Program  (ATMES) 

The  ERDA-sponsored  ATMES  Program,  managed  by  Argonne  National 
Laboratory,  is  concerned  with  development  and  evaluation  of  central 
energy  supply  systems  for  communities.  Existing  and  emerging 
technologies  are  being  scanned  for  their  potential  application  in 
such  systems,  and  the  most  promising  design  concepts  are  evaluated 
in  detail.  It  is  anticipated  that  a large  number  of  different  sys- 
tem configurations  will  have  to  be  considered  and  therefore  a highly 
flexible  and  modular  computerized  energy  modeling  program  is  needed 
to  aid  the  design  team.  Strong  emphasis  is  also  placed  on  short 
run  times  and  ease-of-use. 

The  program  will  simulate  the  quasi-steady  state  operation  of  a 
user-defined  component  configuration  for  a selected  period  of  time, 
generally  in  hourly  increments.  Plant  operation  will  be  simulated 
in  accordance  with  one  of  the  following: 

a.  User-defined  operating  rules. 

b.  Weighted  resource  energy  minimization. 

c.  Operating  and  maintenance  cost  minimization. 

A library  of  component  subroutines  will  be  provied  with  the 
program  and  will  contain  performance  and  economic  data  for  various 
central  plant  components.  This  library  will  be  updated  as  new  data 
and  components  are  evaluated.  Component  subroutines  will  be  readily 
modifiable  by  the  program  user. 

The  executive  program  will  process  the  input  data  utilizing  the 
default  dictionary  to  generate  a standard  file,  analyze  the  informa- 
tion flow  in  the  system  and  decide  on  the  order  in  which  the  components 
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have  to  he  simulated.  The  program  will  then  simulate  the  operation 
of  the  plant  and  calculate  fuel  inputs  for  time  increments  requested 
by  the  user.  A novel  optimization  algorithm  was  developed  which 
can  "operate"  the  plant  to  minimize  fuel  input  or  costs.  This  will 
represent  a significant  improvement  over  simple  simulation  and  will 
indicate  the  capabilities  or  limitations  of  the  system  when  operated 
according  to  the  optimal  strategy.  An  economic  analysis  will  evalu- 
ate initial,  operational,  and  life-cycle  costs  of  the  plant.  It 
could  be  run  independently  of  the  simulation  portion  of  the  program. 

The  input  into  the  program  will  consist  of  two  parts: 

a.  Description  of  the  plant  configuration,  operat- 
ing procedures,  reports  required,  etc.,  given 
in  the  System  Definition  and  Control  Language 
(SDCL) . 

b.  A file  containing  community  energy  require- 
ments to  be  supplied  by  the  plant  (generally 
in  hourly  increments),  e.g.,  electricity,  hot 
water,  steam,  chilled  water,  etc.,  and  other 
variables,  such  as  weather.  The  structure  of 
this  file  can  be  specified  in  the  SDCL. 

The  basic  output  of  the  program  will  consist  of  the  following 
elements : 

a.  Amounts  of  fuel  input  into  the  plant  during  time 
intervals  specified  by  the  user. 

b.  Plant  outputs,  distinguishing  between  outputs  used 
to  satisfy  community  demand  and  those  produced  for 
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sale  to  other  users  outside  the  community. 

c.  Information  on  plant  operation.  For  example, 
statistics  of  equipment  usage  (possibly  in  a form 
of  a load  duration  curve),  and  operating 
strategies  used  by  the  optimization  feature  of 
the  program. 

d.  Results  of  economic  analysis,  i.e.,  first,  O&M,  and 
life-cycle  costs  of  the  plant. 
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